March 2009 - Boost - lists.boost.org

[Review] Reminder: Boost.RangeEx review is going on
by Thorsten Ottosen 02 Mar '09

02 Mar '09

Dear Developers and Users, The review of Neil Groves' RangeEx library lasts until March 3, 2009. Please find the time to do a review if you are interested in this library. The discussion so far may be found here: http://archives.free.net.ph/message/20090220.122836.73bdbd04.en.html Below you will find a description of the library and information on how to write a review. best regards Thorsten, review manager What is it? +++++++++++ The library provide two very useful extensions to the range library 1. Range-based algorithms. E.g. boost::sort( rng ); which is a convenient wrapper of instead of std::sort( boost::begin(rng), boost::end(rng) ); But the new interface also allows for more expressive code because (on the fly) composition of algorithms suddenly is possible. 2. Range adaptors. E.g. std::vector<int> vec = ...; boost::copy( vec | boost::adaptors::reversed, std::ostream_iterator<int>( std::cout ) ); where the expression "vec | boost::adaptors::reversed" wraps the iterators of the range on the left in reverse iterators. The library provides a wide range (no pun intended) of Range adaptors, and they are a powerful way to create ranges on the fly and pass them to algorithms. Getting the library +++++++++++++++++++ The library may be downloaded from http://www.cs.aau.dk/~nesotto/boost/range_ex.zip or from the Boost vault under "Algorithms". The docs may be browsed online here http://www.cs.aau.dk/~nesotto/boost/libs/range/ Please note that the documentation is integrated with the current Range ilbrary. Therefore the relevant sections for the review is http://www.cs.aau.dk/~nesotto/boost/libs/range/doc/adaptors.html and http://www.cs.aau.dk/~nesotto/boost/libs/range/doc/algorithms.html The code may be browsed here: http://www.cs.aau.dk/~nesotto/boost/boost/range/ Notice the library is header only (exception: the adaptor tokenized() depends on Boost.Regex). Writing a review ++++++++++++++++ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager. Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick - reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Special considerations ++++++++++++++++++++++ Various RangeEx like libraries have been implemented in the past. You might want to compare with those libraries when you form your oppinion: 1. John Torjo's range lib http://rangelib.synesis.com.au/libs/boost-rangelib-20040913.zip http://torjo.com/rangelib/index.html 2. Adobe's ASL libraries include range-based algorithms: http://stlab.adobe.com/group__algorithm.html I'm looking forward to your review. best regards Thorsten, Review Manager

4 5

[threadpool] parallel_sort example
by vicente.botet 02 Mar '09

02 Mar '09

Hi, I have implemented a parallel sort with the threadpool library (version 21 http://tiny.cc/HVOOa )+patch to have tp::task default constructibe, and the Boost.Range reviewed currently. (attached the test file). Well a have implemented a generic algorithm that should works to other partition and compose problems. template < typename DirectSolver, typename Composer, typename AE, typename Range > void inplace_solve( AE & ae, boost::sub_range<Range> range, unsigned cutoff ); template < typename DirectSolver, typename Composer, typename AE, typename Range > void inplace_solve( AE & ae, boost::sub_range<Range> range, unsigned cutoff) { unsigned size = boost::size(range); if ( size <= cutoff) DirectSolver()(range); else { partition<Range> parts(range, BOOST_PARTS); task_type tasks[BOOST_PARTS]; for (unsigned i=0;i < BOOST_PARTS-1; ++i) { task_type tmp(ae.submit( boost::bind( &inplace_solve<DirectSolver,Composer,AE,Range>, boost::ref(ae), parts[i], cutoff ))); tasks[i] = tmp; } inplace_solve<DirectSolver,Composer,AE,Range>(ae, parts[BOOST_PARTS-1], cutoff); for (unsigned i=0;i < BOOST_PARTS-1; ++i) { tasks[i].wait(); }; Composer()(range); } } struct sort_fct { template<class RandomAccessRange> RandomAccessRange& operator()(RandomAccessRange rng) { return boost::sort(rng); } }; struct inplace_merge_fct { template<class BidirectionalRange> BidirectionalRange& operator()( BidirectionalRange rng) { return boost::inplace_merge(rng, boost::begin(rng)+(boost::size(rng)/2)); } }; // this implementation mask the ThreadPool. template <typename Range> void parallel_sort(Range& range, unsigned cutoff=10000) { pool_type pool( boost::tp::poolsize( 2) ); boost::sub_range<Range> rng(boost::begin(range), boost::end(range)); inplace_solve<sort_fct,inplace_merge_fct,pool_type,Range>( pool, rng, cutoff); } The differences in time on my computer are not too good. The sort has been done on a reversed container and the container sorted for 400000 elements parallel_sort xxx: where xxx is the cutoff parameter with BOOST_PARTS=2 std::sort: reverse 0..400000 37 milli seconds std::sort: 0..400000 35 milli seconds boost::sort: reverse 0..400000 38 milli seconds boost::sort: 0..400000 34 milli seconds parallel_sort 200000: reverse 0..400000 24 milli seconds parallel_sort 200000: 0..400000 24 milli seconds parallel_sort 100000: reverse 0..400000 28 milli seconds parallel_sort 100000: 0..400000 26 milli seconds parallel_sort 50000: reverse 0..400000 31 milli seconds parallel_sort 50000: 0..400000 29 milli seconds parallel_sort 25000: reverse 0..400000 32 milli seconds parallel_sort 25000: 0..400000 34 milli seconds parallel_sort 12500: reverse 0..400000 37 milli seconds parallel_sort 12500: 0..400000 34 milli seconds My computer has only two cores. I expected that with a cutoff of 50.000 we will have a better time that withh a cutoff of 200.000. Could someone having access to a computer with more cores run the test in order to compare the results I have also implemented parallel_sort without masking the pool template <typename AE, typename Range> void parallel_sort(AE& ae, Range& range, unsigned cutoff=10000) { boost::iterator_range<typename boost::range_iterator<Range>::type> rng(range); inplace_solve<sort_fct,inplace_merge_fct,pool_type,Range>( ae, rng, cutoff); } and in this case we win ~3 mili seconds for the creation of the Thread Pool. std::sort: reverse 0..400000 37 milli seconds std::sort: 0..400000 35 milli seconds boost::sort: reverse 0..400000 36 milli seconds boost::sort: 0..400000 34 milli seconds parallel_sort 200000: reverse 0..400000 27 milli seconds parallel_sort 200000: 0..400000 23 milli seconds parallel_sort 100000: reverse 0..400000 29 milli seconds parallel_sort 100000: 0..400000 27 milli seconds parallel_sort 50000: reverse 0..400000 29 milli seconds parallel_sort 50000: 0..400000 30 milli seconds parallel_sort 25000: reverse 0..400000 31 milli seconds parallel_sort 25000: 0..400000 29 milli seconds parallel_sort 12500: reverse 0..400000 32 milli seconds parallel_sort 12500: 0..400000 27 milli seconds This let me think that the application should not create ThreadPools for specific algorithms, but use a default one. The V21 of Boost.ThreadPool provide a boost::this_task::get_thread_pool<pool_type>(), but this function works only if called from a task. It should be great if the Boost.ThreadPool provided a default pool which could be recovered with this function on threads that are not worker threads of a ThreadPool. Otherwise the application is forced eother to add a parameter to all the functions or define its own default thread pool statically. Oliver you are free to take this as example for the ThreadPool documentation, if you consider this can improve the understanding of what can be done with your library. Best, Vicente

4 8

N2346 - Defaulted and Deleted Functions emulation
by vicente.botet 02 Mar '09

02 Mar '09

Hi, is there an interest in a N2346 - Defaulted and Deleted Functions emulation http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm The idea been to use some macros that will use the =default, =delete if the compiler provides it and replace this macros by whatever has the same semantics. Alexandrescu introduced already two macros NON_ALIAS and NON_HEAP_ALLOCATED when talking about strict locks. Attached a draft for the default and deleted functions. Only one remark the macors must be used on the public part and without trailing ';', e.g. class X { BOOST_NEW_DELETE(X) Any coments are welcome, Vicente

3 6

Re: [boost] [utility] new auto_buffer class --- RFC
by Felipe Magno de Almeida 02 Mar '09

02 Mar '09

On Mon, Mar 2, 2009 at 3:46 PM, Daniel Hulme <st(a)istic.org> wrote: > On Mon, Mar 02, 2009 at 03:21:58PM -0300, Felipe Magno de Almeida wrote: >> is rarely what the user wants. I wanted auto_buffer to be a SBO class with >> a STL interface. > > Neither Google nor Wikipedia know what you mean by "SBO". (I'm guessing > it's not Small Bowel Obstruction.) Could you clarify this term in your > next post to the list, please? Sorry, It means Small Buffer Optimization. Regards, -- Felipe Magno de Almeida

1 0

[geometry] gtl review pre-announcement
by Tom Brinkman 02 Mar '09

02 Mar '09

I'm doing a session at boostcon about GIL and making a bunch of examples, including some about GTL. You can include those as part of your unit test cases if you like. //Tom

3 2

RPC library in the sandbox
by Jon Shuler 02 Mar '09

02 Mar '09

Does any know if the author(s) of this library are still around and plan to make any more updates to it? Jon

2 1

[config] borland/codegear problems with C++0x macros
by Beman Dawes 01 Mar '09

01 Mar '09

* trunk/boost/config/compiler/borland.hpp: It looks like John Maddock and I independently added C++0x macros. The resulting inconsistencies need to be reconciled. The BOOST_CODEGEAR_0X_SUPPORT macro doesn't appear to be documented, by the way. John, do you want to take a whack at this? * trunk/boost/config/compiler/codegear.hpp: Doesn't have the negative C++ macros yet. I'd like to borland.hpp finished before trying to do codegear.hpp. Thanks, --Beman

2 2

RangeEx review
by Phil Endecott 01 Mar '09

01 Mar '09

My RangeEx review follows. I'm afraid that I have not been following much of the ongoing discussion of this library on the list so apologies if I simply repeat what other people are saying. Algorithms ---------- I have always found the verbosity of things like std::sort(container.begin(),container.end()) to be an embarrassing misfeature of the std library so it's good to be able to now write the much more sensible sort(container). Just a couple of comments: - It would be good if the docs were explicit about this being a thin wrapper around your existing std::sort, and identifying those algorithms that are not so thin. - Do we really want this in the top-level boost:: namespace? There have been discussions about sorting libraries for Boost who might also want boost::sort. Would it not be better to put these algorithms in a boost::range namespace? Then we move on to the algorithms where you can select what is returned using a template parameter. This is an interesting idea, but it's a little verbose and I can't think of any precedent for it in the std library or elsewhere in Boost. Being unfamiliar increases the learning curve for a feature. I was wondering if it would be possible to have something more like: boost::unique(rng).found instead of boost::unique<boost::return_found>(rng) Or maybe not; just a thought. You then have this example for sorting and removing duplicates: boost::erase( vec, boost::unique<boost::return_found_end>( boost::sort(vec) ) ); Err... yuk. Why can't I write: unique(vec); Or maybe unique(sort(vec)); or sort(vec); unique(vec); My point is that std::unique only has its "move duplicates to the end" behaviour because the conventional interface with a pair of iterators doesn't let you change the size of the container. Now that we have a unique() that takes a container we don't need that restriction. I recently tried to write a starts_with algorithm: template <typename CONTAINER> bool starts_with(const CONTAINER& a, const CONTAINER& b) { // does a start with b ? return std::equal(b.begin(), b.end(), a.begin()); } The problem with this is that it will crash if a is shorter than b, because std::equal takes only three not four iterators. The fix is to add an additional test: return a.size() >= b.size() && std::equal(b.begin(), b.end(), a.begin()); Unfortunately, for containers where size() is O(N) this makes the algorithm O(N+M), which is especially problematic if the common case if for a difference to be found early in the sequences. So I was curious to see if range::equal addresses this problem: it has the potential to do so since it has access to all four ends of the containers. According to the docs the complexity is "Linear. Exactly distance(rng) comparisons." which doesn't look hopeful, but what "rng" is it referring to? Looking at the source, however, it seems that it does have an optimal implementation. I think this needs a documentation fix. This also makes me wonder if these would be useful algorithms: bool longer(rng1,rng2); bool equal_length(rng1,rng2); bool size_greater_than(rng,size_t); bool size_equal_to(rng,size_t); Adaptors -------- The author seems to be very enthusiastic about chaining functions using operator|. I'm not inherently opposed to this idea but I don't think it should be the role of this library, RangeEx, to provide it. In my opinion this feature should be a general-purpose one. Example: y = sqrt ( sin (x) ); In natural language we may choose to describe that as "the square root of the sine of x" or "take the sine of x and then take the square root of that". If the second of those seems more "natural" to you then you may prefer to write: y = x | sin | sqrt; or maybe even y = (sin | sqrt) (x); I guess that someone who is better at metaprogramming than me could write a general-purpose operator| that can be used in this way. Here's a start: template <typename T1, typename T2, typename T3> struct chained_func { typedef function<T1(T2)> f1_t; typedef function<T2(T3)> f2_t; f1_t f1; f2_t f2; chained_func(f1_t f1_, f2_t f2_): f1(f1_), f2(f2_) {} T1 operator()(T3 arg) { return f1(f2(arg)); } }; template <typename T1, typename T2, typename T3> chained_func<T1,T2,T3> operator|(function<T1(T2)> f1, function<T2(T3)> f2) { return chained_func<T1,T2,T3>(f1,f2); } template <typename T1, typename T2, typename T3> T1 operator|(T3 val, chained_func<T1,T2,T3> cf) { return cf(val); } This feature could then be available for any purpose that the user prefers, including range adaptors, and RangeEx users who don't want to use it can ignore it entirely. (For all I know, maybe this already exists somewhere.) Even if you choose to keep operator| I suggest making the documentation less "evangelical". Quote: "Why do I prefer the operator| syntax? The answer is readbility:" and you go on to show one version that uses operator| and one that doesn't. I would argue that the version using operator| is _less_ readable simply because it uses operator|, and the reader will wonder why you're doing a bitwise OR between a vector and a, umm, a something else. Of course anyone who reads the documentation will understand it, but one of the best features of this library is that, as in the example of sort(container), the functions do "exactly what they say on the tin", and a casual reader of code using it doesn't need to have digested the docs first. Quote: * boost::copy_if( rng, pred, out ) * boost::count_if( rng, pred ) These algorithms are not defined and the reason is that both of them can be expressed by using the original algorithm togther with a Adaptor Generator: The fact that something can be expressed using a combination of other things is not a sufficient justification for leaving it out. For example, sort(container) could be expressed as sort(container.begin(),container.end()) yet you have still provided it. Why should I have to write: int n_zeros = count( container | boost::adaptors::filtered(_1==0) ); instead of int n_zeros = count_if(container, _1==0); ? Summary ------- - What is your evaluation of the design? I would prefer that operator| be factored out. Otherwise I am satisfied with the design. - What is your evaluation of the implementation? I have not properly studied the implementation, but I have not seen any problems in the code that I have looked at. - What is your evaluation of the documentation? Good. - What is your evaluation of the potential usefulness of the library? The basic feature of being able to pass containers to algorithms makes it useful enough to justify inclusion. - Did you try to use the library? With what compiler? Did you have any problems? I did some very basic experiments with gcc 4.1 on linux, with no problems. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A couple of hours. - Are you knowledgeable about the problem domain? Not especially. - Do you think the library should be accepted as a Boost library? I would prefer to see the operator| stuff factored out, as described above. But given the choice between including the library as-is or not including it at all I would choose to include it as is, since the algorithms alone are sufficiently useful to justify inclusion. Regards, Phil.

2 3

[thread] static thread_specific_ptr?
by k-oli＠gmx.de 01 Mar '09

01 Mar '09

Hello, can I create an static thread specific pointer for class which will initalized by different threads? struct X { static thread_specific_ptr< U > tss_ptr_; }; in some threads: X::tss_ptr_.reset( new U); And for each thread X::tss_ptr_ will point to a different object in the freestore? Oliver

6 8

rule cpp-pch unknown in module Jamfile</D:/boost/trunk/libs/math/build>?
by Peter Dimov 01 Mar '09

01 Mar '09

I'm trying and failing to run the smart_ptr tests because of: D:\boost\trunk\libs\smart_ptr\test>bjam ..\..\..\libs\math\build\Jamfile.v2:8: in modules.load rule cpp-pch unknown in module Jamfile</D:/boost/trunk/libs/math/build>. D:/boost/trunk/tools/build/v2/build\project.jam:313: in load-jamfile D:/boost/trunk/tools/build/v2/build\project.jam:62: in project.load D:/boost/trunk/tools/build/v2/build\project.jam:742: in project.use D:/boost/trunk/tools/build/v2/build\project.jam:89: in load-used-projects D:/boost/trunk/tools/build/v2/build\project.jam:73: in load D:/boost/trunk/tools/build/v2/build\project.jam:115: in load-parent D:/boost/trunk/tools/build/v2/build\project.jam:448: in initialize D:/boost/trunk/tools/build/v2/build\project.jam:303: in load-jamfile D:/boost/trunk/tools/build/v2/build\project.jam:62: in load D:/boost/trunk/tools/build/v2/build\project.jam:168: in project.find D:/boost/trunk/tools/build/v2\build-system.jam:535: in load D:\boost\trunk\tools\build\v2/kernel\modules.jam:283: in import D:\boost\trunk\tools\build\v2/kernel/bootstrap.jam:138: in boost-build D:\boost\trunk\boost-build.jam:17: in module scope -- Peter Dimov http://www.pdplayer.com

4 7