March 2009 - Boost - lists.preview.boost.org

[scope_exit] Boost.ScopeExit capturing 'this'
by adam.butcher＠selex-comms.com 11 May '09

11 May '09

I wasn't sure whether I had the correct address for Boost.ScopeExit's author Alexander Nasonov, so I've submitted to this list just in case and to get feedback from other users. I have been playing with BOOST_SCOPE_EXIT -- it it very convenient. One thing I would have liked would be to capture 'this' inside member functions. I have created a patch which adds BOOST_SCOPE_EXIT_THIS to do just that. It provides an operator->() in the generated struct which can be used to access the enclosing class's members. The syntax is: BOOST_SCOPE_EXIT_THIS( (&a) (&b) ) { a; b; // local captures (*this)->member; // member access } BOOST_SCOPE_EXIT_END; and can be BOOST_SCOPE_EXIT_THIS() { (*this)->member; } BOOST_SCOPE_EXIT_END; providing the preprocessor allows for empty parameter lists (which gcc does and vc does albeit after disabling a warning to remove noise). The type pointed to by the result of operator->() is correctly cv qualified. It has been tested on gcc 4.3, gcc 4.2, msvc 7.1 and msvc 9.0. I don't have access to other compilers. Boost.Typeof worked fine on gcc for typeof(this) -- mostly because gcc has a native typeof I guess. On visual studio (vc71 and vc90) it was not so good -- a compiler bug ( http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedba… , http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedba… ) that has been marked as 'Won't fix' means that 'this' cannot be used in expressions within template argument lists -- even if those expressions are innocuous typeid()s or sizeof()s for type-inference. The common workaround (capturing a compile-time integer with an enumerator and using the enumerator in the template parameter list) doesn't work with the vc71-specific implementation of Boost.Typeof since it is based on typeid() -- this cannot be captured in a compile-time expression (or I know of no way to that doesn't involve the expression existing in a template argument list). All is not lost though -- the general-purpose sizeof() based approach for the other VC versions works fine for VC71 for determining the typeof 'this'. As such my patch includes a VC>=1300 specific workaround for typeof 'this' determination. This is unfortunate but I couldn't think of any other non-intrusive way of doing it. Please find the attached patch and let me know what you think -- I'm sure this feature would be useful to users -- it saves having to do: TypeOfMyClassWhichCouldBeTedious* self = this BOOST_SCOPE_EXIT( (&self) ) { self->member; } BOOST_SCOPE_EXIT_END; which removes the convenience of BOOST_SCOPE_EXIT in these contexts since something like: struct at_end { TypeOfMyClassWhichCouldBeTedious* self; ~at_end() { self->member; } } at_end = {this}; can be done without any dependencies to achieve the same result. Regards, Adam. ------------------------------------------------------------ This email and any attached files contains company confidential information which may be legally privileged. It is intended only for the person(s) or entity to which it is addressed and solely for the purposes set forth therein. If you are not the intended recipient or have received this email in error please notify the sender by return, delete it from your system and destroy any local copies. It is strictly forbidden to use the information in this email including any attachment or part thereof including copying, disclosing, distributing, amending or using for any other purpose. In addition the sender excludes all liabilities (whether tortious or common law) for damage or breach arising or related to this email including but not limited to viruses and libel. SELEX Communications Limited is a Private Limited Company registered in England and Wales under Company Number 964533 and whose Registered Office is Lambda House, Christopher Martin Rd, Basildon, SS14 3EL. England.

4 8

[Graph] transitive reduction
by boese-wolf＠math.uni-frankfurt.de 30 Apr '09

30 Apr '09

Hi! May I propose the following implementation for a transitive reduction to be added to the boost graph library? I'm a novice and the quality of the code I produced surely does not meet boosts standards, but maybe with some help, I'm able to improve it. So, please don't shoot me. #ifndef MY_OWN_TRANSITIVE_REDUCTION_HPP_INCLUDED #define MY_OWN_TRANSITIVE_REDUCTION_HPP_INCLUDED #include <vector> #include <algorithm> //std::find #include <boost/concept/requires.hpp> #include <boost/concept_check.hpp> #include <boost/graph/topological_sort.hpp> #include <boost/graph/graph_traits.hpp> #include <boost/property_map.hpp> //I actually didn't care which of those heades include some of the //others and whicht could be left out, for this reason, I simply added a //header when I used a function, described to be in this header by the //boost graph documentation //also I didn't got all of the concepts thin. Am I suppose to check //for all concepts, which are needed for functions I call? (As if I //wouldn't do that, the users would see the functions called by //complaining about missings concepts, which would be clearly an error //message revealing internal implementation and should therefore be avoided?) //the pseudocode which I followed implementing this algorithmn was taken //from the german book Algorithmische Graphentheorie by Volker Turau //it is proposed to be of O(n + nm_red ) where n is the number //of vertices and m_red is the number of edges in the transitive //reduction, but I think my implementation spoiled this up at some point //indicated below using namespace boost; template <typename Graph, typename GraphTR, typename G_to_TR_VertexMap, typename VertexIndexMap> BOOST_CONCEPT_REQUIRES( ((VertexListGraphConcept< Graph >)) ((IncidenceGraphConcept< Graph >)) ((MutableGraphConcept< GraphTR >)) ((ReadablePropertyMapConcept< VertexIndexMap, typename graph_traits<Graph>::vertex_descriptor >)) ((Integer< typename property_traits< VertexIndexMap >::value_type >)) ((LvaluePropertyMapConcept< G_to_TR_VertexMap, typename graph_traits<Graph>::vertex_descriptor >)), (void)) transitive_reduction( const Graph& g, GraphTR& tr, G_to_TR_VertexMap g_to_tr_map, const VertexIndexMap & g_index_map ) { typedef typename graph_traits<Graph>::vertex_descriptor Vertex; typedef typename graph_traits<Graph>::vertex_iterator VertexIterator; typedef typename std::vector<Vertex>::size_type size_type; std::vector<Vertex> topo_order; topological_sort( g, std::back_inserter( topo_order ) ); std::vector<size_type> topo_number_storage( num_vertices(g) ); iterator_property_map<size_type*, VertexIndexMap, size_type, size_type&> topo_number( &topo_number_storage[0], g_index_map ); { typename std::vector<Vertex>::reverse_iterator it = topo_order.rbegin(); size_type n = 0; for(; it != topo_order.rend(); ++it,++n ) { topo_number[ *it ] = n; } } std::vector< std::vector< bool > > edge_in_closure(num_vertices(g), std::vector<bool>( num_vertices(g), false)); { typename std::vector<Vertex>::reverse_iterator it = topo_order.rbegin(); for( ; it != topo_order.rend(); ++it ) { g_to_tr_map[*it] = add_vertex(tr); } } for( typename std::vector<Vertex>::iterator it = topo_order.begin(); it != topo_order.end(); ++it ) { size_type i = topo_number[ *it ]; edge_in_closure[i][i] = true; std::vector<Vertex> neighbors; //I have to collect the successors of *it and traverse them in //ascending topological order. I didn't know a better way, how to //do that. So what I'm doint is, collection the successors of *it here { typename Graph::out_edge_iterator oi,oi_end; for( tie(oi, oi_end) = out_edges( *it, g ); oi != oi_end; ++oi ) { neighbors.push_back( target( *oi, g ) ); } } { //and run through all vertices in topological order for( typename std::vector<Vertex>::reverse_iterator rit = topo_order.rbegin(); rit != topo_order.rend(); ++rit ) { //looking if they are successors of *it if( std::find( neighbors.begin(), neighbors.end(), *rit) != neighbors.end() ) { size_type j = topo_number[ *rit ]; if( not edge_in_closure[i][j] ) { for(size_type k = j; k < num_vertices(g); ++k) if( not edge_in_closure[i][k] ) //here we need edge_in_closure to be in topological order, edge_in_closure[i][k] = edge_in_closure[j][k]; //therefore we only access edge_in_closure only through //topo_number property_map add_edge(g_to_tr_map[*it], g_to_tr_map[*rit], tr); } //if ( not edge_in_ } //if (find ( } //for( typename vector<Vertex>::reverse_iterator } // { } //for( typename vector<Vertex>::iterator } //void transitive_reduction #endif //#ifndef MY_OWN_TRANSITIVE_REDUCTION_HPP_INCLUDED Best regards, Eric

2 3

Proposed templated integer_sort
by Steven Ross 25 Apr '09

25 Apr '09

Would there be interest in an integer_sort call that is faster than std::sort? Spreadsort is an in-place hybrid radix-based and comparison-based algorithm with better worst-case and average-case (roughly 20-50%) performance than introsort on random integer data. The worst-case advantage is algorithmic, with Spreadsort taking the better of O(n(square_root(bit_sizeof(data) - log(n)))) and O(nlog(n)) time. For 32-bit integers, that's O(n(square_root(32 - log(n)))), so for a log(n) of 16 (65536 items), it's 4n (plus a small constant times n), vs 16n for introsort. For larger n, the advantage vs. pure comparison-based algorithms increases. In effect, Spreadsort smoothly transitions from pure MSB Radix sort to std::sort with its data cut up by a couple iterations of MSB Radix sort (reducing the size of the log(n) factor), depending upon the distribution and size of the data. I could write a templated version of Spreadsort for the Boost library if there is interest. It would work for anything that supports the << and - operators. It could also handle standard floats sorted as integers. Functors supporting << and - could make it more general. Multi-dimensional sorting is also sped up by Spreadsort. I could also write a similar string_sort, that should also be significantly faster than std::sort. This would look much like postal sort, just using introsort after a certain number of iterations. Is this of interest? http://sourceforge.net/projects/spreadsort

15 118

[thread] atomic
by Sergei Politov 15 Apr '09

15 Apr '09

Hi, I would like to known state of atomic (class/operations) implementation in boost. There are several threads that contains references to atomics, but I cannot find the state of this issue. May be I've overlooked something. I would like to known the following: 1) Is there defined interface for atomics? Where is it if present? 2) What is the state of this work? Currently I use my own implementation of atomic class. It has interface similar to atomic class from intel tbb (also it contains some ideas from tbb, but AFAIK ideas are not under GPL license). Now it is tested on MSVC 9.0 32-bit, and GCC 4.2.4 under Gentoo linux (both 32 and 64-bit). I can boostify and prepare it for review, if there is no such work already in progress. Best Regards, Sergei

4 3

Boost.Process 0.3 released
by Boris 14 Apr '09

14 Apr '09

I've released Boost.Process 0.3. Here's the documentation and a link to download the zip archive: Docs: http://www.highscore.de/boost/process/ Code: http://www.highscore.de/boost/process.zip It's a header-only library and thus pretty easy to use: Just copy the files to your Boost directory. In this release my main goal was to merge various snapshots: * There was my Boost.Process 0.2 version which was based on Boost.Process 0.1 from 2006. * There was a post-0.1 version of Boost.Process in SVN from 2007. * Chris Fairles had modified a Boost.Process snapshot for Unix platforms. * Ion Gaztañaga had also some ideas and bug fixes he sent to this mailing list recently. I just saw that Ilya Sokolov created another snapshot based on Boost.Process in SVN. That means we have again at least two different versions of Boost.Process. :-/ In my Boost.Process 0.3 version I concentrated on merging and overhauling code. I did not change the design but tried to make the code work: All the code which was written since 2006 should become usable. That's why I also concentrated a lot on test cases. There are quite a lot of test cases, and they all can be built and passed successfully on three platforms with four compilers. As it would be great if others run the test cases, too (ideally on new platforms), I'll send another message in a few minutes with a description how to run the test cases yourself. As the documentation was written in 2006 I also updated it. It's not yet really a good documentation: There are some files coming from 2006 while other files I wrote myself only last week. While the documentation can be improved it's at least up-to-date: The examples all work and can be compiled. As the documentation was not my priority for Boost.Process 0.3 it should be ok for now. Boris

9 14

[mpl][fold.html] apply<op, _1, deref<_2> > correction needed.
by Larry Evans 13 Apr '09

13 Apr '09

The vault file: http://preview.tinyurl.com/cbr9k3 demonstrates the bug. What's the correct value for the ForwardOp arg to iter_fold in http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/fold.html? TIA. -Larry

5 20

[convert] Version in the Vault ready for review.
by Vladimir.Batov＠wrsa.com.au 13 Apr '09

13 Apr '09

After listening to many views, opinions, suggestions I've re-done boost::convert and would like it scheduled for a review. It is certainly nowhere as MPL and still not perfect. However, I believe it will be very useful to many developers (like me) not satisfied with lexical_cast and not (yet?) needing (or ready for) something like upcoming Spirit 2.0. Overall, after weighing all pros and cons, I am reasonably happy with the current interface and implementation. It does not implement all that have been discussed and suggested. It is most unlikely implemented the way some would like it to see. However, I had to make choices I felt comfortable with and I feel the current interface is minimal, readable and allows for further growth. With that review-request I would like to avoid opening up another round of discussions if 'from' was a good, bad, mediocre choice. I feel we've exhausted that topic and I would like people to simply vote if they find the functionality needed. I am most certainly prepared to eat my humble pie if the vote is 'no'. Still, I am very much looking forward to any implementation-related suggestions/corrections or new ideas we have not discussed so far. The current interface can be summed up as with as little as int i = convert<int>::from(str); // Throws on failure int i = convert<int>::from(str, -1); // Returns -1 on failure More details can be found in the accompanying document (just remember I am not Shakespeare). If/when we decide to extend that by incorporating, say, Boost.Parameter and/or Spirit, then it might be as int i = convert<int>::from(str)(radix_ = 10, more_parm_ = ...); int i = convert<int>::from(str)(some Spirit related stuff); I am prepared to look into it further... if this initial proposal is accepted... otherwise, it'll be less work for me. :-) Thank you everyone who participated in the lexical_cast/convert discussions. Your views, opinions, suggestions were very helpful and educating and are very much appreciated. I hope I did not forget anyone in the "acknowledgements" list. The file called boost-string-convert.zip can be found in the Vault at http://www.boostpro.com/vault/. Thanks, Vladimir.

6 17

[mpl][docs]why use list?
by Larry Evans 13 Apr '09

13 Apr '09

Comparing the vector doc: http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/vector.html which contains: supports constant-time insertion and removal of elements at both ends, and linear-time insertion and removal of elements in the middle. with the list doc: http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/list.html which contains: supports constant-time insertion and removal of elements at the beginning, and linear-time insertion and removal of elements at the end and in the middle. shows these documents indicate no reason to prefer list over vector but does indicate a reason to prefer vector over list. Is there any reason to prefer list over of vector? -regards, Larry

4 13

boost/pool/pool.hpp why reinterpret_cast instead of static_cast?
by Philippe Vaucher 12 Apr '09

12 Apr '09

Hi, In the file https://svn.boost.org/trac/boost/browser/trunk/boost/pool/pool.hpp there's the following code: struct default_user_allocator_malloc_free { ... static char * malloc(const size_type bytes) { return reinterpret_cast<char *>(std::malloc(bytes)); } ... }; It is my understanding that void* to T* convertions should be done using static_cast and not reinterpret_cast. Is there a reason for using reinterpret_cast there? Thanks, Philippe

7 11

[filesystem] Version 3 request for comments
by Beman Dawes 12 Apr '09

12 Apr '09

A prototype implementation of version 3 of Boost.Filesystem is available for comment. The critical feature of this prototype is the replacement of the class basic_path template with a single class path that supports both narrow and wide character paths. It also supports user supplied types, and will support the new C++0x char16_t and char32_t character types as compiler and standard library support becomes available. There is still a lot of additional work before V3 could be added to the trunk and eventually released. For example, work so far has concentrated on the new functionality, and ignored breaking changes to existing code. But enough stuff is working to make requesting comments useful. See http://svn.boost.org/svn/boost/sandbox/filesystem-v3/libs/filesystem/doc/v3… for a fuller description of the prototype and links to the prototype implementation. I've got some specific issues I'd like opinions on, but would first like to hear comments from anyone interested. --Beman

11 21

[gsoc] improving any and variant
by Mathias Gaunard 07 Apr '09

07 Apr '09

A few little ideas that could eventually be joined to be a single GSoC project: - Allow visitation for Any. This can actually be generalized to any object that exposes a type_info, such as polymorphic objects. Techniques, including non-portable ones based on name mangling, could be experimented to get more efficient dispatch. - Add SBO to any. - Improve variant so that the functor doesn't require to expose a result_type. The result_type can be automatically deduced by "joining" all the possible return types obtained by boost::result_of. - Allow the easy construction of a visitor from lambda expressions, with a syntax like variant<int, std::string> a = "foo"; int b = match(a).with( args<int>(_1), args<std::string>(size(_1)) ); instead of the potentially more verbose struct my_visitor : static_visitor<int> { int operator()(int a) { return a; } int operator()(const std::string& b) { return b.size(); } }; variant<int, std::string> a = "foo";; int b = apply_visitor(my_visitor(), a);

5 5

[boost test] boost testing framework xml schema‏
by Daniel Carrara 06 Apr '09

06 Apr '09

I would like to know where I can find the xml schema for the test logs produced at the end of the testing with --log_level=all and _log_format=XML. Thanks, Daniel _________________________________________________________________ Windows Live™ SkyDrive: Get 25 GB of free online storage. http://windowslive.com/online/skydrive?ocid=TXT_TAGLM_WL_skydrive_032009

2 1

[mpl][doc]bug: prior.html should have Bidirectional Iterator requirement.
by Larry Evans 06 Apr '09

06 Apr '09

The prior.html document: http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/prior.html says prior requirement is that Iterator be a Forward Iterator; yet, http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/forward-iterato… makes no mention of prior. Also, compiling prior on a list iterator shows: /home/evansl/prog_dev/boost-svn/ro/boost-trunk/boost/mpl/next_prior.hpp:40: error: no type named 'prior' in 'struct boost::mpl::l_iter<boost::mpl::list1<char> >' Hence, the prior requirement should be Bidirectional instead of just Forward Iterator. -regards, Larry

2 1

My ideas for GSoC project
by Balša Raičević 05 Apr '09

05 Apr '09

Hello, I'm a Computer Science student from Faculty of Mathematics, University of Belgrade. I am interested in working on The BGL. I have a lot of experience with C++ and code refactoring also, since I've done a lot of tutoring and encountered a lot of strange students' code :) I have taken a deep look at BGL ( which is why I'm writing my proposal so late :) ) and to some extend its extension - The Parallel Boost Graph Library. I am mostly interested in graph partitioning, as I find them very useful for parallel computing. I understood the importance of it when I had to do some major calculations for numerical approximations and wanted to use all the CPU power available :) In the project idea list ( https://svn.boost.org/trac/boost/wiki/soc2009#Graphpartitioning) it's said that it would be good to implement algorithms similar to those in METIS ( http://www.cs.umn.edu/~metis <http://www.cs.umn.edu/%7Emetis>). I've read some of George Karypis' "Publications Related to Graph Partitioning", so I was wondering if I could discuss with someone which algorithms would be good to implement, and of course, how. I found little, if any, discussion about that in mailing list archive. Other thing I would really like to see is hypergraph partitioning. I see that implementing hypergraphs in the BGL is one of GSoC projects, so I would like to know would it be possible, if that project is not awarded to anyone for this summer, to do basic implementation of a hypergraph, or (since I see there is already a discussion about that) if somebody else would do that project, to collaborate on hypergraph partitioning algorithms. Last, but not least, an important question: I would like to use this work as part of my Master's Thesis. I looked at GSoC FAQ ( http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs#cours…) so I guess it is OK with the program, but I would still like to discuss it with potential mentor. Thanks ahead, Balsa

1 1

[GSOC] Regarding the project Boost.DeVector
by Satyam Shekhar 04 Apr '09

04 Apr '09

Hi, I am interested in doing the Boost.DeVector project for GSOC 2009. I had certain queries regarding this project: 1. Does the standard specify any sort of implementation for deque, or does it only specify the requirements and interface? I ask this because if we assume a dynamic array implementation which grows on both the sides, implementing 'reserve', and specifying the size of the chunk should be a trivial task. 2. What are the examples of the low-level operations for which this container is over-encapsulated? Regards Satyam

6 14

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 02 Apr '09

02 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

[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

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

How to generate a Bernuolli number
by Barco You 01 Apr '09

01 Apr '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