- Boost - lists.preview.boost.org

A Boost.NumericAdaptor library to support big numbers
by Bruno Lalande 02 Apr '09

02 Apr '09

Hello, Barend quickly talked about this in the discussion about robustness, big numbers and GMP. We have discussed about the idea and I'd like to present it here to see if there's an interest. The idea started from the need to rely on big numbers in geometry computations that are sensitive to floating point errors. The most important points were: - big numbers are needed for those computations - it's difficult to develop a Boost Big Numbers library as efficient as the existing ones - having a Boost geometry library that *necessarily* depends on an existing big numbers library would impose to the user the way in which big numbers must be handled, and would imply a dependency that apparently disturbs some people Thus we had the idea of using an adaptor, that is a wrapper that would have the same semantics as a number, with an underlying implementation chosen at compile-time, by selecting a policy. There would be a IEEE policy that doesn't use any big number at all, and other policies that would be implemented upon the most widely used big numbers libraries. In the end it appears that this adaptor could become a library on its own since it can be useful in other libraries than just geometry. It could thus take the form of a Boost.NumericAdaptor library, aimed to any library developer who needs to optionally enable the use of big numbers for the most robustness-sensible operations of his library. He would just have to take a policy as a template parameter, and propagate this policy to a Numeric Adaptor used internally. The first user of this library would obviously be the GGL we're developing. Libraries like the fixed-size matrix being currently discussed as a GSoC project could offer take advantage of this kind of library, since ideally it has to support big numbers. The sample in attachment shows the numeric_adaptor, a IEEE policy, a GMP policy and a sample showing the use of the library. The implementation has to evolve of course, but the main points are here. Would there be an interest in adding such a library into Boost? Bruno Lalande Barend Gehrels

7 10

Back to Boost.SIMD - Some performances ...
by Joel Falcou 01 Apr '09

01 Apr '09

I'm still working on a potential Boost.SIMD proposal despite the apparent lack of interest by the list. Last discussion spawned the fact that actual performances figures may be interesting. So here's some (see end of mail). This table show for a subset of non-trivial functions the cycles needed to compute one value in scalar, using SSE2, some precision concerns and the actual speed-up. Most of them are super-linear because either : 1/ libc algorithm is badly implemented, or 2/ non-SIMD architectural difference between SSE2 FPU and scalar FPU leads to additional speed-up Most transcendental functions used a SIMD evrsion of the old yet useful Cephes C library based around various polynomial estimations. Results on Altivec processor are roughly the same except for transcendental where the use of a proper FMA instead of sequence of mul-add increases performances.For trivial function like +,-,*,/, I was happily surprised that indeed gcc is able to generate SIMD code. Alas, gcc auto-SIMD speed-up never exceed 2.54 while our code can go up to 3.5. Concerning the problem of interface and support of odd-ball vector size in a platform independant fashion, we use the remark of Matthias and provide a vec<T,C> class in which the vector cardinal can be speficified (and is equal to the native cardinal of said type by default). Things like vec<double,5> are handled as boost::array and provide same interface and set of functions. for any given functions, it cna be applied either to any vec<T,C> types or any native SIMD type (__m128 in SSEx or vector xxx in Altivec). Syntaxic sugar like v = v+4 is provided and perform consatnt splatting before SIMD evaluation. This still has to be boostified and made independant of the whole project it depends on. Once done, a preliminary version will be uploaded into the Vault. Current target architecture are : - SSE2, SSSE3,SSE3 - AltiVec for PPC and Cell processor (a patched version of boost is needed) Comments and questions welcomed. || -------------- || --------------- || scalar || -------------- vector ---------------- || ---- || || || || cycles ||cycles | ulp | rms | peak || s-up || || --------------------------------------------------------------------------------------------- || || abs_ || float || 2.0 || 0.8 | 0 | 0.00e+00 | 0.00e+00 || 2.4 || || acosh_ || float || 148.2 || 30.2 | 1 | 9.15e-09 | 1.19e-07 || 4.9 || || acos_ || float || 261.8 || 14.7 | 3 | 7.01e-08 | 2.38e-07 || 17.8 || || arg_ || float || 5.0 || 1.2 | 0 | 0.00e+00 | 0.00e+00 || 4.2 || || asinh_ || float || 152.8 || 32.4 | 1 | 1.22e-08 | 1.19e-07 || 4.7 || || asin_ || float || 256.5 || 11.6 | 2 | 5.32e-08 | 2.28e-07 || 22.1 || || atanh_ || float || 123.9 || 20.4 | 2 | 2.27e-08 | 4.55e-07 || 6.1 || || atan_ || float || 160.7 || 12.7 | 1 | 3.55e-08 | 6.74e-08 || 12.7 || || bitofsign_ || float || 5.1 || 0.8 | 0 | 0.00e+00 | 0.00e+00 || 6.1 || || boolean_ || float || 5.4 || 1.0 | 0 | 0.00e+00 | 0.00e+00 || 5.4 || || cbrt_ || float || 152.5 || 39.7 | 1 | 2.76e-08 | 7.77e-08 || 3.8 || || ceil_ || float || 16.6 || 2.8 | 0 | 0.00e+00 | 0.00e+00 || 5.9 || || cosh_ || float || 211.5 || 19.1 | 2 | 4.00e-08 | 1.83e-07 || 11.1 || || cos_ || float || 112.2 || 14.6 | 1 | 2.98e-08 | 1.11e-07 || 7.7 || || cospi_ || float || 103.6 || 12.1 | 1 | 3.43e-08 | 1.19e-07 || 8.6 || || cot_ || float || 142.8 || 17.8 | 3 | 5.54e-08 | 2.38e-07 || 8.0 || || cotpi_ || float || 142.1 || 17.1 | 6 | 9.62e-08 | 4.08e-07 || 8.3 || || exp10_ || float || 169.3 || 32.1 | 1 | 2.88e-08 | 1.19e-07 || 5.3 || || exp_ || float || 171.3 || 19.3 | 1 | 2.60e-08 | 1.19e-07 || 8.9 || || expm1_ || float || 294.1 || 42.6 | 3 | 2.89e-08 | 1.94e-07 || 6.9 || || floor_ || float || 16.9 || 2.7 | 0 | 0.00e+00 | 0.00e+00 || 6.4 || || gd_ || float || 602.4 || 35.8 | 3 | 3.93e-08 | 2.46e-07 || 16.8 || || indeg_ || float || 2.2 || 0.8 | 0 | 2.59e-08 | 5.94e-08 || 2.7 || || inrad_ || float || 2.2 || 0.8 | 0 | 2.53e-08 | 5.94e-08 || 2.6 || || iseqz_ || float || 5.5 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 6.3 || || iseven_ || float || 45.0 || 2.3 | 0 | 0.00e+00 | 0.00e+00 || 19.9 || || isfin_ || float || 5.9 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 6.6 || || isflint_ || float || 38.3 || 1.8 | 0 | 0.00e+00 | 0.00e+00 || 21.4 || || isgez_ || float || 6.0 || 0.8 | 0 | 0.00e+00 | 0.00e+00 || 7.4 || || isgtz_ || float || 6.0 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 6.5 || || isinf_ || float || 6.0 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 6.5 || || islez_ || float || 5.0 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 5.8 || || isltz_ || float || 5.0 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 5.8 || || isnan_ || float || 3.0 || 0.8 | 0 | 0.00e+00 | 0.00e+00 || 3.6 || || isnegative_ || float || 5.6 || 1.1 | 0 | 0.00e+00 | 0.00e+00 || 5.0 || || isnez_ || float || 5.4 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 6.2 || || isnotfinite_ || float || 3.0 || 0.8 | 0 | 0.00e+00 | 0.00e+00 || 3.6 || || isodd_ || float || 47.8 || 2.5 | 0 | 0.00e+00 | 0.00e+00 || 18.8 || || ispositive_ || float || 5.6 || 1.3 | 0 | 0.00e+00 | 0.00e+00 || 4.2 || || log10abs_ || float || 107.5 || 17.3 | 2 | 6.59e-08 | 2.12e-07 || 6.2 || || log10_ || float || 105.4 || 16.9 | 2 | 6.58e-08 | 2.12e-07 || 6.2 || || log1p_ || float || 149.7 || 18.8 | 1 | 9.16e-09 | 1.19e-07 || 8.0 || || log2abs_ || float || 107.5 || 17.2 | 1 | 1.89e-08 | 1.19e-07 || 6.3 || || log2_ || float || 105.5 || 17.1 | 4 | 1.90e-08 | 2.51e-07 || 6.2 || || logabs_ || float || 107.5 || 23.6 | 1 | 4.36e-08 | 1.19e-07 || 4.6 || || log_ || float || 108.3 || 15.4 | 1 | 9.12e-09 | 1.19e-07 || 7.0 || || mantissa_ || float || 22.1 || 5.0 | 0 | 0.00e+00 | 0.00e+00 || 4.4 || || oneminus_ || float || 3.3 || 0.8 | 0 | 5.16e-10 | 5.96e-08 || 4.0 || || oneplus_ || float || 3.4 || 0.8 | 0 | 2.87e-10 | 5.74e-08 || 4.1 || || rec_ || float || 37.4 || 4.3 | 0 | 2.48e-08 | 5.92e-08 || 8.8 || || round_ || float || 43.7 || 5.5 | 0 | 0.00e+00 | 0.00e+00 || 8.0 || || rsqrt_ || float || 105.4 || 11.3 | 1 | 3.62e-08 | 8.81e-08 || 9.3 || || signedbool_ || float || 9.3 || 0.9 | 0 | nan | 0.00e+00 || 10.6 || || sign_ || float || 12.1 || 2.5 | 0 | 0.00e+00 | 0.00e+00 || 4.9 || || signnz_ || float || 12.1 || 1.4 | 0 | 0.00e+00 | 0.00e+00 || 8.5 || || sinh_ || float || 267.2 || 19.1 | 3 | 2.38e-07 | 3.84e-07 || 14.0 || || sin_ || float || 110.5 || 17.0 | 1 | 2.98e-08 | 1.12e-07 || 6.5 || || sinpi_ || float || 115.8 || 14.4 | 1 | 2.98e-08 | 1.10e-07 || 8.0 || || sqr_ || float || 2.0 || 0.7 | 0 | 2.53e-08 | 5.94e-08 || 2.9 || || sqrt_ || float || 68.3 || 7.1 | 0 | 2.62e-08 | 5.96e-08 || 9.6 || || sqrtabs_ || float || 68.3 || 7.0 | 0 | 2.61e-08 | 5.96e-08 || 9.7 || || tanh_ || float || 206.4 || 20.8 | 197 | 1.63e-07 | 1.77e-05 || 9.9 || || tan_ || float || 153.0 || 17.8 | 2 | 4.18e-08 | 1.45e-07 || 8.6 || || tanpi_ || float || 156.2 || 18.0 | 2 | 4.16e-08 | 1.48e-07 || 8.7 || || --------------------------------------------------------------------------------------------- || -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

9 23

[Boost.Asio] Compiler warning in address_v6.hpp
by Fraser Hutchison 01 Apr '09

01 Apr '09

I'm new to boost and am looking for a bit of advice if possible. asio/ip/address_v6.hpp lines 58 & 355 yield the following compiler warnings when flag -Wmissing-braces (which is enabled by -Wall) is set: missing braces around initializer for 'u_char [16]' missing braces around initializer for 'in6_addr::<anonymous union>' These can be avoided by amending e.g. line 58 from boost::asio::detail::in6_addr_type tmp_addr = IN6ADDR_ANY_INIT; to boost::asio::detail::in6_addr_type tmp_addr = {{IN6ADDR_ANY_INIT}}; Is this worth submitting a bug report and patch for this, or not?

3 2

personal samsung
by Fernando Cacciola 01 Apr '09

01 Apr '09

11 6 100 6359

1 1

[gsoc] Proposal - Boost.Matrix - DRAFT RFC
by Kornel Kisielewicz 01 Apr '09

01 Apr '09

Hello all, Following the discussion in the threads: "[boost][gsoc] Interest check for 3d geometry proposal" "[boost] [gsoc] fixed size matrix class?" I post a draft of my proposal with a request for comments. Following the suggestions I decided to scale down the proposal to a polished and production-quality fixed-size Boost.Matrix library, with a big emphasis on correctness and performance. The application follows: Abstract ========= uBLAS is Boost's general linear algebra library, and it is a fine library indeed. However, in some cases it's design decisions, while quite rational for the general use case, are restrictive. This proposal is about a new library that would address some of these issues in the specific situation of vector and matrix operations on fixed sized structures. Suggested is a new library boost::matrix. The library would introduce a single container class that allows representation of fixed size vectors and matrices, and their respective standard operations. The library would define the following template template<typename T, std::size_t N, std::size_t M, class Traits> matrix and standard operations on it. The class would make heavy use of template specialization to allow efficient vector operations ( matrices with size 1xN ), and provide efficient operations for the common sizes (2-4). The class will provide the interface of STL containers with the exact concept depending on the Traits used. Care will be taken to allow transparent usage within STL and other boost libraries. Rationale ========== Boost.Matrix aims to be for uBLAS, what Boost.Array is for vectors -- a fixed size version to remove the overhead. The need is however greater, because while uBLAS provides a template for a fixed-sized version of it's arrays, the template is just a cover for the original uBLAS matrices. While the performance is comparable, the size includes a unnecessary field size. In cases that make heavy use of fixed sized matrices and vectors ( like real-time computer graphics ), such a tradeoff is unacceptable -- due to increased memory consumption as well as effective vectorized math operations, and alignment of structures passed ( a single 4D vector should effectively fit a 128 bit register, and a single 128 bit move operation ). Also, knowing the dimensions of a matrix/vector at compile time, allows for a more efficient operation implementation, both from the programmers side ( better algorithms ), as well as from the compilers side ( optimization ). Primary deliverables ===================== Boost.Matrix library, with the following features: a) a boost::matrix base container class for 2-dimensional matrices, with the proper behavious and semantics of a container, written following the boost coding guidelines, and with full portability in mind b) specializations for efficient vector (1xN matrix) handling c) operators for readable but efficient vector/matrix math d) operator specializations for matrices and vectors of the most common size (2-4) for most efficient implementation Secondary deliverables ======================= a) performance test suite, for testing optimizations b) unit tests for the whole library providing full operation coverage and code-coverage c) documentation for the whole library in the BoostBook format d) efficient implementation of interoperability of Boost.Matrix with other boost libraries (uBLAS in particular) Bonus deliverables =================== ( if time allows these will be delivered during program timeline, if not, they will be implemented afterwards ) a) optional (compile-time controlled) integration with Boost.SIMD to boost (no pun intended) performance b) performance tests on different compilers/architectures, further optimizations c) support for further boost libraries ( Boost.Assign, sandbox libraries, etc. ) Design issues ============== a) compile-time concept checking to only generare functions that make sense for the given type ( no floating point operations for integral types ) b) usage of templates to unroll the operations at compile-time to allow the compiler to optimize them ( needs to be tested case by case with the performance test suite ) c) usage of expression templates to eliminate temporaries in expressions d) care to keep most useful memory alignment ( to provide ease of use with direct usage in architecture dependent pipelines ) e) design with architecture-dependent optimizations in mind ( ease of expansion ) f) keeping all the standard boost practices, including workarounds for non-conformant compilers Project schedule ================= I plan to do at least weekly progress reports with emphasised design decisions (however well designed in the first phase, reality will probably change the design afterwards at least a little). Progress reports will be directed to the medium established with the mentor (blog, list or only direct communication). This will be my only job once summer starts, and will be treated as such during program coding timeline ( full-time schedule ) -- a week may fall out for a short vacation. Preplanning (April 20 - May 23) -------------------------------- Most of the major design decisions need to be done before the program starts. A end-user interface for the library should be established before the program starts. This will be summed up in a report that will be sent to boost-dev with a request for comments. Phase 1 (Correctness) - (May 24 - June 14) ------------------------------------------- A working basic (non-optimized) implementation, and a full test suite for the basic operations will be created. Goal for this phase is to provide a correct and working implementation. Basic usage document. Phase 2 (Functionality) - (June 14 - July 5) --------------------------------------------- Performance test suite. Compiler-level optimizations ( expression templates, unrolling, etc ). Basic library compatibility ( STL container, uBLAS ). Concept checking. Phase 3 (Optimization) - (July 6 - July 26) -------------------------------------------- Optimizations for vectors, optimizations for specific vector and matrix sizes, optimization checking through performance test suite. Code review for eventual optional architecture optimization ( Boost.SIMD for example ). General optimization of code. Update of documentation. Phase 4 (Finalization and bonuses) - (July 27 - August 10+) ------------------------------------------------------------ Testing on as many architectures as possible ( probably will need some help here ). Fixes. Cleanup of the code where needed. A report of the implementation that again will be posted to boost-dev with a request for comments. Here is included also buffer time if there will be delays in one of the former phases. If not, work will continue with the Bonus deliverables. Brief resume ============= I'm a Computer Science PhD student (2nd year) at the University of Wroclaw (Poland), in the field of Computer Graphics. My interests lie in Game Programming and Design, with a special hunch for Real-time Proceduraly Generated Content. I actively run self-designed courses and lectures at the University ( 3ds MAX course last year, Game Programming lecture this semester, and probably an Advanced C++ course next semester ). Currently, until the end of the semester, I'm working full-time at Tieto corporation, doing a large scale project for Nokia. Previously I worked at a smaller computer game company working on a massive multiplayer game. I've successfully taken part in two last GSoC's creating a Procedural City Generator for the BZFlag project. I consider myself a fairly competent C++ programmer, although I only recently discovered its true strengths ( learned to properly use and write in the style of STL, started reading Boost sources, and got hooked into C++0x ). I'm currently using the language both at work and for my own projects. The latter include a 3D game engine (in progress), and an unannounced space combat/trading game. I am a big fan of roguelike (ASCII) games, and managed to write several roguelikes up to date, the most famous one of them being DoomRL ( http://doom.chaosforge.org ) that did even get mentions in contemporary gaming magazines. Homepage : http://chaosforge.org/ IRC nick : Epyon E-mail : kornel.kisielewicz at gmail.com / epyon at cs.uni.wroc.pl -- regards, Kornel Kisielewicz

7 14

Extrinsec conversions (Was [safebool] Can we generalize it and put it intoutilities?)
by vicente.botet 01 Apr '09

01 Apr '09

----- Original Message ----- From: "Eugene Wee" <crystalrecursion(a)gmail.com> To: <boost(a)lists.boost.org> Sent: Wednesday, April 01, 2009 4:10 AM Subject: Re: [boost] [safebool] Can we generalize it and put it intoutilities? > > Hi, > > On Wed, Apr 1, 2009 at 6:20 AM, Vladimir Batov > <vladimir.batov(a)wrsa.com.au>wrote: > >> I glanced over "explicit conversion operators" in C++0x. It did not struck >> me as >> relevant to safe_bool. Care to elaborate? > > > It is relevant since you can say, define an explicit conversion function to > convert to bool, and yet avoid the very problems with say, also allowing > implicit conversion to int, that the safe bool idiom is used to avoid. In > other words, it is a language feature directly designed to replace the safe > bool idiom, and more. Hi, Thanks for the clarification. Even if the following is not related to the safe bool idiom it is related to conversions. The current standard allows to define intrinsec coversions, i.e. conversions that are defined either as a conversion operator on the from class or as a constructor on the to class. Vladimir StringConvert proposal seems to go towards a conversion from/to strings (If I've understood?). lexical_cast can be seen as an extrinsec converions of unrelated types via a common type stream type. I have proposed a generic convert_to template function that generalize extrinsicaly the explicit convertion of unrelated types. template <typename To, typename From> To convert_to(From&); One difference is that for C++0x explicit conversion you can write From from; To to=To(from); While for unrelated types you are forced to write From from; To to=convert_to<To>(from); The other difference is that constructors and conversion operators can be implicit, while the convert_to function can not. Do you think that it could be an interest in extending the C++0X standard to take care of these extrinsically defined conversions between unrelated types? Have a sens to have extrinsec conversions which implicitly convert? Should this convert_to<T> operator be considered as a friend class of T? I know that this is out of the scope of Boost, but I just wanted to know your opinion before posting to comp.lang.c++.moderated. Apologize if this has already been discused. Best, Vicente

3 2

[safebool] Can we generalize it and put it into utilities?
by Vladimir.Batov＠wrsa.com.au 01 Apr '09

01 Apr '09

Repeating safe-bool scaffolding over and over again is a real nuisance. It is worse for the end users as not exactly everyone is intimately familiar with the issue and the safe-bool workaround. Can we generalize it and put something like the following into utilities? struct safebool { typedef void (safebool::*unspecified_bool_type)() const; typedef unspecified_bool_type result; explicit safebool(bool v) : value_(v) {} operator result() const { return value_ ? &safebool::internal_bool : 0; } private: void internal_bool() const {}; bool value_; }; That way all we (and the users) will have to do to deploy the technique will be class Foo { ... operator safebool::result() const { return safebool(my_condition); } }; This seems simple and hassle-free. Thanks, Vladimir.

8 19

[gsoc] Concept check
by Kasra 01 Apr '09

01 Apr '09

Hi, I have decided to use the following concept for my gsco proposal regarding boost.crypto. The dilema at the moment what is the minimum contiguous ranges concept? Any suggestiong over the design? concept CryptoBuffer // which is a variable sized buffer that // uses an allocator that securely deletes. concept BlockCipher { typename value_type; typename size_type; typename traits_type; auto key(void) const throw(); template<CryptoBuffer CB> void key(const CB& ) const throw(invalid_key_size); template<CryptoBuffer CB> void encrypt(CB&, const CB& ) const throw(bad_state); template<CryptoBuffer CB> void decrypt(CB&, const CB& ) const throw(bad_state); }; struct crypto_stream_parallel_encryption { }; struct crypto_stream_parallel_decryption { }; struct crypto_stream_parallel : crypto_stream_parallel_encryption, crypto_stream_parallel_decryption{ }; concept ModeOfOperation { typename value_type; typename size_type; typename block_cipher_type; typename category; static constexpr size_type transform_size; static constexpr size_type state_size; const auto cipher() const throw(); void create() throw(); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type update(CB0& , const CB1&); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type update_final_block(CB0& , const CB1&); }; concept StreamCipher { typename value_type; typename size_type; typename block_cipher_type; typename category; static constexpr size_type transform_size; static constexpr size_type state_size; const auto cipher() const throw(); void create() throw(); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type update(CB0& , const CB1&); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type update_final_block(CB0& , const CB1&); }; concept HashAlgorithm { typename value_type; typename size_type; typename block_cipher_type; typename category; static constexpr size_type state_size; static constexpr size_type transform_size; void create() throw(); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type update(const CB1&); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type finalise(const CB1&); }; Any suggestiong over the design? -- Kasra

1 0

has_operator_new
by Robert Ramey 01 Apr '09

01 Apr '09

I've made a TRAK item to request a new type traits feature - has_operator_new. I've included an implementation and a test - both type_traitsified. Hope you can see fit to check it out, and if it's OK, check it in. Let me know when you do this. Once this is in, I can clear a dependent feature request TRAK item from the serialization library. Robert Ramey

2 3

[gsoc] Interest check for 3d geometry proposal
by Kornel Kisielewicz 01 Apr '09

01 Apr '09

Hello all, I was instructed on the #boost-soc channel to post the initial interest check on the GSoC proposal on the dev list, so here it is. It was inspired by one of the project proposals from 2006 (Geometry Library). As a known fact Boost begins to be used in the gaming industry. Following the idea of code reusage, there are several generic algorithms and components reused by virtually every 3d gaming engine. Most particulary this is 3D math. Sure, Boost has a linear algebra library graph algorithms, and a proposed geometry library, yet what is missing is a high-performance low-dimensional linear algebra library ( vectors and matrices up to the 4th dimension ). Side by side we have also a need of several 3-dimensional algorithms -- including, but not limited to intersection tests, inclusion tests, volume bounding, and several computational geometry algorithms. My suggestion would be creating a 3d specific geometry library for boost, with reasonable performance and the most used algorithms. I'd be happy to work on such a library as a GSoC project. My goal is to assess the initial interest in such an GSoC proposal idea before preparing and posting a more detailed description. -- regards, Kornel Kisielewicz http://chaosforge.org/

22 56

GSoC 2009
by Julian Mautner 01 Apr '09

01 Apr '09

Hi everyone! I'm Julian, 21 years old, student at the university of Innsbruck, Austria. Currently I'm making my bachelor in physics and computer science. I really would like to participate as a GSoC-student of yours. I intend to write a proposal for the Boost.Devector project. But first I wanted to ask a few questions: 1) I didn't understand if devector is an intrusive container or it only has to use them? 2) What does this devector class should (exaclty) be capable to do? 3) Which methods are the most important to perform in O(1)? 4) I didn't used the boost-library very much in the past, is this a great problem for this project? Thanks for your time. Regards, Julian

2 1

[type-traits] compilation error in has_new_operator
by Andrey Torba 01 Apr '09

01 Apr '09

Hi All, After 52057-52061 commits the compilation error oocur: D:\c++\libs\boost_trunk\boost/type_traits/has_new_operator.hpp(40) : error C2039: 'nothrow_t' : is not a member of 'std' to reproduce try to compile: #include <boost/type_traits/has_new_operator.hpp> int main() { return 0; } Does it need #include <new>?

2 1

GSoc Proposals - some friendly advice
by Robert Ramey 01 Apr '09

01 Apr '09

I've been looking through the GSoc proposals with some bemusement. Most of the proposals are projects that will thake MUCH, MUCH more than a summer. I know "But I've almost got it working". I don't think that one can fullly appreciate the effort it takes to make a boost library. I know its very easy to get started. I'm here to tell you its very hard to finish. It's so much more than writing the code. Theres the tests, getting them to pass on all platforms, getting the design past the criticism an reveiws. So here's my advice. Pick something really small that you know you can finish in three months. If you finish too soon, we can give you something else to do. Robert Ramey

3 2

[gsoc] PLEASE SUBMIT PROPOSALS NOW
by troy d. straszheim 31 Mar '09

31 Mar '09

Hi Students, This just in from the director of the GSOC, in an email with lots of asterisks and capital letters in the subject: > I realize that many organizations are working with students to refine > their proposal ideas on their mailing lists, wikis, etc. However, a > proposal on a wiki, mailing list, etc. does not constitute an actual > application for the program; the proposal must be submitted to the > GSoC 2009 site. While doing review and refinement outside of > http://socghop.appspot.com is a useful exercise, it doesn't allow us > to accurately gauge the number of student proposals we're receiving > for GSoC 2009. > > Please help us get an accurate sense of how many proposals will be > submitted for GSoC 2009 by asking your students to submit their > proposals to the GSoC 2009 site *now*. They are welcome to link to the > wiki page, mailing list thread, forum topic, etc. where their > proposals are under discussion and refinement as part of the proposal > submission process.[0] And the [0] refers to: http://socghop.appspot.com/document/show/program/google/gsoc2009/userguide#… Many of you have done a *great* job raising proposals, discussing and refining them. Please get some placeholder applications up asap, even if they aren't completely finished. I'm looking forward to seeing yet more good discussion and refinement of your proposals. Everybody keep up the good work. On behalf of the boost community, thanks for your enthusiasm. :) -t

1 0

How to generate a Bernuolli number
by Barco You 31 Mar '09

31 Mar '09

Hi, I want to randomly generate a Bernuolli number [0, 1],with probability p ~[0 1]. How to do that with boost? Thanks! -- ------------------------------- Enjoy life! Barco You

6 16

[GSoC] Opinions and suggestions for improving CGI library
by Eugene Wee 31 Mar '09

31 Mar '09

Hi everyone, I hope to participate in this year's Google Summer of Code by working on a project for Boost, and would like to get opinions and suggestions on what I intend to do. In GSoC 2007, Darren Garvey worked on a CGI library under the mentorship of Christopher Kohlhoff. This sounded interesting to me, as my first forays into programming were for the Web with PHP, but I never actually used CGI with C++, even though I have been aware of cgicc and Wt for some time. I contacted Darren, who informed me that while he was still working on the library, he lacked the time to implement many features, and would welcome help. There were a number of features that he highlighted, but three of them stood out for me: * Persistent sessions >From my experience with PHP, session handling tends to be a heavily used feature that this CGI library lacks. I intend to design an interface for session handling that would allow the use of memory mapped files (with the help of Boost.Interprocess) and relational databases as storage options. I will also implement session handling with one of the possible storage options. * Improved multipart/form-data parsing Currently, the parsing is done with regex, which is something of a hack in this case. The aim is to replace the use of regex with the use of Boost.Spirit. From what I see, this is also an area that needs more testing, hence developing the test suite would be an important part of this subproject. * Windows support for Fast CGI Portability is one of the goals of Boost, and this is of interest to me personally as I use Windows quite often. However, I am unable to conceive a solution (or even pinpoint the problem) to this right now, but I believe that with time I can figure it out, especially since Darren has some idea as to what might need to be done. For reference: Darren's proposal abstract: http://code.google.com/soc/2007/boost/appinfo.html?csaid=5869D5120647336D Current documentation: http://omnisplat.com/docs/ In Boost sandbox: https://svn.boost.org/svn/boost/sandbox/SOC/2007/cgi/ Thank you, Eugene Wee

6 9

How to bind objects with reference handle
by Altaf Navalur 31 Mar '09

31 Mar '09

Hello All, I am using the latest version of boost. I am trying to bind a particular member function to a signal. I am trying to bind the signal to a pointer, which is a reference Handle(WeakRefHandle,RefHandle). I am getting an error for this. How do I fix it. I am trying to port a game, So switching to boost::shared_ptr is not an option, as it will force lot of changes in the game code. Cheers, Altaf -- An eye for an eye only ends up making the whole world blind.

2 1

Google SoC idea - Relations
by Michael Lopez 31 Mar '09

31 Mar '09

Hello everyone. I am an undergraduate student of Kent State University and I am drafting a proposal for GSoC to try and extend the BGL. I don't exactly know to whom I should direct this post, but I wanted to informally pass this idea to the boost community. I would like to add a binary relation data type to the BGL. Binary relations are quite similar to graphs and can be visualized using directed graphs. I would even like to use the graph interface for relations, since one of its key features should be that a user can use relations just as she would use graphs. Sometimes, a single criterion is all that is needed to define a relation (an edge) between two objects (vertices). This relation can be a '<' operator or '>=' operator or something more complex, for instance an equivalence relation between some geometric shapes. It doesn't really matter. The beauty in this datatype is that the relation, in the form of a function, will be user defined. I would like to provide several common relations such as less than and modular equivalence, but the relation is completely up to the user and packed snugly into a familiar interface that is quite capable of handling relations. Speaking of snug packing, the other key feature that differentiates relations from graphs is data storage. The relation data type will store a set of objects rather than vertices and edges. Since the relation is defined as a function, checking to see whether there is a relation (an edge) between two objects (vertices) simply requires a function call with those two objects as parameters. This bypasses the look up of an edge in favor of a computation. The computation, however, does not have to be limited to a boolean value. In the case of weighted complete graphs, the relation can be utilized as a normal functions, such as distances between cities. Better yet, the Boost.optional can be used to return either a type or false if a relation does not exist. Time permitting, I would also like to examine the possibility of providing support for properties like transitivity and symmetry and also provide a data type that would enable closures, such as transitivity (connectivity). who am I: Like I mentioned above, I am a KSU student majoring in both mathematics and computer science. I've been programming in c++ since early highschool. good heavens, that would be about 8 years. I am fascinated by generic and template programming and enjoy applications of math in programming, particularly visulaization and applications of discrete math. thank you for reading, michael lopez

4 3

[mirror] -- RFC
by Matus Chochlik 31 Mar '09

31 Mar '09

Dear Boosters, The Mirror library has been around for nearly a year. I would like to start doing the preparations for getting the library ready for a formal review and before that I would like to hear your opinions on whether this library actually belongs to Boost and any suggestions on how to improve it or what to change. For those of you who are not familiar with it, Mirror is a compile-time reflection facility with some run-time features. The sources can be downloaded from the Vault or checked out from the Sandbox (http://svn.boost.org/svn/boost/sandbox/mirror/) Since the docs (http://tinyurl.com/atba2k) do not cover everything yet, you can see the usage of several of the implemented but undocumented features in the test suite and in the examples (http://tinyurl.com/c4xygh) Some people have found the Concept browser (http://tinyurl.com/czz3t2) to be a good starting point and a useful quick reference. It, however, requires a XSLT capable web browser. It is known to work with MSIE 7+ and Firefox 3.x.y without the need to install any other software. Best regards, ________________ ::matus_chochlik

5 9

[thread] Error: cannot open file 'libboost_thread-vc90-mt-gd-1_38.lib'
by Santosh Naidu 30 Mar '09

30 Mar '09

Hi All, I am new to Boost. I am getting the following error when I try to include <boost/thread/condition_variable.hpp> Error 1 fatal error LNK1104: cannot open file 'libboost_thread-vc90-mt-gd-1_38.lib' I have followed all the steps to setup the boost library given in the startup document. Regards, Santosh

3 2

[thread] Assertion failed get_system_time_sentinel()
by Filip Klasson 30 Mar '09

30 Mar '09

Hi, I get Assertion failed timed_lock(::boost::detail::get_system_time_sentinel()), file c:\boost\thread\win32\basic_timed_mutex.hpp, line 64. Code in basic_timed_mutex.hpp: void lock() { BOOST_VERIFY(timed_lock(::boost::detail::get_system_time_sentinel())); //Line 64 } Code in thread_time.hpp: namespace boost { ... namespace detail { inline system_time get_system_time_sentinel() { return system_time(boost::posix_time::pos_infin); } ... } } I read in a previous thread that this was a known bug that is fixed in Boost 1.38 but i am using Boost 1.38. Is this another bug or is it not fixed? This only happends sometimes and it happends when i call wait on a condition variable. Here is my code, i have marked where Assertion failed happends. boost::mutex::scoped_lock lock(_mutex); while(_queue.empty()) { _condition.wait(lock); } //Assertion failed happends here. //Another thread is signaling the condition variable when an element is added to the _queue. I am happy with all sorts of helpful comments. Best regards

4 6

[iostreams] binary memory stream
by Kenny Riddile 30 Mar '09

30 Mar '09

I'm still pretty inexperienced with the iostreams library, so this may be a simple question. I'm trying to use GIL to write a PNG to a memory stream instead of a file stream. The write_view() function in the new version of GIL's io extension expects an ostream opened in binary mode as it's first parameter, such as: using namespace std; using namespace boost::gil; ofstream outputStream( "foo.png", ios::out | ios::binary ); write_view( outputStream, const_view(image), png_tag() ); I'm attempting to write to memory instead of a file, by doing this: using namespace boost::gil; using namespace boost::iostreams; typedef stream< back_insert_device< std::vector<char> > > BufferStream; std::vector<char> buffer; BufferStream bufferStream( buffer ); write_view( bufferStream, const_view(image), png_tag() ); The data that ends up in buffer is identical to the data that ends up in foo.png from the first example if I don't open outputStream in binary mode. So how can I make a binary memory stream with the iostreams library? Do I need to write my own filter?

4 6

Re: [boost] unicode tools and an unicode string type
by Graham 30 Mar '09

30 Mar '09

8. Re: [gsoc] unicode tools and an unicode string type (Mathias Gaunard) >It's really aimed at being simple and non-intrusive. Components are >fairly separate and code is thus incremental, and the unicode string >just composes the work. > >I personally believe basic_string, char_traits, and codecvt facets and >the standard locale system are not really suitable to deal with unicode, >which may have been the reason why previous proposals ended up they way >they did. >I think some people said the same in the various unicode discussions, too. >Efficient algorithms are provided by the Unicode consortium, so it's >mostly just the design or glue code that needs work. >The glue depending on what integration with other components is being >done. Here, it's mostly just range concepts. Mathias, Unfortunately the simple algorithms supplied by the Unicode consortium all end up requiring a character traits tables ! There are large tables that need to be transformed into compact sets of traits and this was done by myself and Rogier. These traits are then used to drive simple [ish] rules. So whatever you do - you need to start with the character traits tables [which are large]. Yours, Graham Barnett

1 0

Re: [boost] unicode tools and an unicode string type
by Graham 30 Mar '09

30 Mar '09

> Re: [gsoc] unicode tools and an unicode string type (Mathias Gaunard) Mathias, We are overdue a full string Unicode support library in boost. Rogier and I developed the Unicode character library that was going to underly the Unicode string libraries to provide full Unicode char, string, and iterator support [grapheme, word, paragraph iterators etc] but never had time to complete it. Any compliant Unicode text presentation system will need this and it is not possible to write a compliant Unicode text editor without it. Please have a look at the Unicode character library at: http://www.boostpro.com/vault/ Unicode_lib.zip. Good luck. Yours, Graham Barnett

1 0

[proto] transforms && rvalue refs
by troy d. straszheim 30 Mar '09

30 Mar '09

I'm playing with proto on gcc 4.3 with c++0x enabled and trying to see if I can use rvalue refs inside callable transforms, to tell what is/isn't temporary while transforming an expression. I have a different way to do this, involving embedding the 'rvalueness' of an object in its type... yuck. Hopefully something better is out there. The use case: a = exp(exp(b)); (as below), where a and b are terminals and exp is a proto lazy function. This expression should result in only one copy of b... You'd want the inner call 'exp(b)' to see that it is being passed an lvalue, copy the value to a temp, modify and return std::move(temp). The outer call to exp() should see that an rvalue has arrived and feel free to overwrite it and return it by std::move. I think. The closest I can get is below. I thought I'd ask for a sanity-check on this before go any further... I have the feeling the check will come back negative. Thanks in advance, -t #include <boost/proto/proto.hpp> #include <boost/ref.hpp> #include <cassert> namespace bp = boost::proto; // // Tag for calls to exp() in our DSEL // struct exp_tag { friend std::ostream& operator<<(std::ostream& os, exp_tag) { return os << "exp_tag"; } }; // // The terminal. Assume this thing is very heavy. Some construtors // have assert(0) in them to verify they aren't called. // // struct array_impl { std::string name; array_impl() : name("NONAME") { } array_impl(const std::string& name_) : name(name_) { std::cout << "name=" << name << "\n"; } // // constructors // array_impl(array_impl& rhs) : name(rhs.name + "_copied") { } array_impl(const array_impl& rhs) : name(rhs.name+ "_copied") { } array_impl(array_impl&& rhs) { name.swap(rhs.name); name += "_moved"; } array_impl& operator=(array_impl&& rhs) { name.swap(rhs.name); name += "_moved"; return *this; } // // not called // array_impl& operator=(array_impl& rhs) { assert(0); // just to be sure what is and isn't getting called } array_impl& operator=(const array_impl& rhs) { assert(0); // just to be sure what is and isn't getting called } array_impl& operator=(const array_impl&& rhs) { assert(0); // just to be sure what is and isn't getting called } friend std::ostream& operator<<(std::ostream& os, const array_impl&) { return os << "array_impl"; } }; // // The transform for calls to exp. You'd like to be able to see if // this is getting called with a movable object. // struct UnaryFnCall : bp::callable { typedef array_impl result_type; template <typename Tag> result_type operator()(Tag, const array_impl& t) { std::cout << "transform a const ref\n"; array_impl tmp(t); return std::move(tmp); } template <typename Tag> result_type operator()(Tag, array_impl&& t) { // this guy doesn't get called, but I'd like him to. assert(0); // if this trips, something good happened. return std::move(t); } }; struct Grammar : bp::or_<bp::when<bp::terminal<array_impl>, bp::_value>, bp::when<bp::unary_expr<exp_tag, Grammar>, UnaryFnCall(exp_tag(), Grammar(bp::_child0))> > { }; template <typename T> struct Expression; struct Domain : bp::domain<bp::pod_generator<Expression>, Grammar> { }; template <typename Expr> struct Expression { BOOST_PROTO_EXTENDS(Expr, Expression<Expr>, Domain); }; template<class T> typename bp::result_of::make_expr< exp_tag, Domain, T& >::type exp (T&& t) { return bp::make_expr<exp_tag, Domain>(boost::ref(t)); } // // Our expression type that // struct array : public Expression<bp::terminal<array_impl>::type> { typedef array_impl impl_t; impl_t& self() { return boost::proto::value(*this); } array() { assert(0); } array(const std::string& name) { self().name = name; } array(const array&) { assert(0); } array(array&&) { assert(0); } template <typename Expr> array& operator=(Expr const& expr) { bp::display_expr(expr, std::cout); BOOST_MPL_ASSERT(( bp::matches<Expr, Grammar> )); typedef typename boost::result_of<Grammar(Expr const&)>::type result_t; result_t r = Grammar()(expr); self().operator=(std::move(r)); return *this; } }; int main(int, char**) { array a("a"), b("b"); // Here, only one copy is made a = exp(b); std::cout << "a's name:" << a.self().name << "\n\n"; // Here, two copies are made a = exp(exp(exp(b))); std::cout << "a's name:" << a.self().name << "\n"; }

3 8