- Boost - lists.boost.org

[thread] thread-safe static local
by Oliver Kowalke 04 Mar '09

04 Mar '09

Hi, I need a function 'get_default_X()' returning a reference to a singleton in a multithreaded env. I choosed Scott Meyers singleton pattern (static local) together with boost::call_once(). My this be a reasonable, threadsafe implementation? regards, Oliver -- Computer Bild Tarifsieger! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 ¿/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

5 5

Boost.Test: documenting a little Mac OS X usage nit
by Owen Smith 03 Mar '09

03 Mar '09

Greetings! I'd like to present a little tiny puzzle that took me an embarrassingly long time to solve--a year, to be specific. (OK, maybe a day poking around, followed by a year being buried in the bug queue. :-) ) With this comes a couple of requests for the Boost.Test documentation. If i understand correctly, the Boost.Test library boost_unit_test_framework is a little bit odd in that the static version of the library carries a main() routine (which I intend to take advantage of) whereas the dynamically linked version does not. In Mac OS X, with the standard MacPorts installation of boost, this poses a problem because both static and dynamic libraries are built and installed to the same location. When linking with gcc using my usual -L and -l options, given the choice, the linker will always select the dynamic library, and I will be missing my main(). (I should point out this would be a non-issue if the main() routine were in a different library that you could choose to include or not include as you wish, but I'm assuming this battle has long since been fought and resolved.) First, I know the main() issue has been mentioned many times on the list before, but I couldn't find any documentation of it in the 1.38.0 manual. This seems like a significant issue to document--am I just missing it somewhere? Second, the best workaround we found for this problem was to explicitly select the static library by foregoing the -L and -l options and directly specifying <full-path>/libboost_unit_test_framework-mt.a as one of the linker arguments. And this is what I'd like to see documented--either as a footnote to "Unit Test Framework > User's guide > Usage variants > Static library", or maybe as part of the topic "Unit Test Framework > Usage recommendations > Generic". I'm happy to prepare documentation patches if desired. Thanks! -- O

1 0

[math] Does any one interesting in calculating derivative for a expression automatically?
by Kasra 03 Mar '09

03 Mar '09

Hi, I think the function are rather interesting in fact I really like differential calculations with the way you have implemented it. If you give more information about your implementation maybe we could work something out. -- Kasra

1 0

boost::bind, problem with result type deduction and calling conventions
by Ingo.Loehken＠boc-eu.com 03 Mar '09

03 Mar '09

hi, anybody able to explain, why the code for the result type, related to special calling conventions defines an void return type ? template< class R, class T > struct add_cref< R (T::*) (), 1 > { typedef void type; }; so that code like class A { public: int __stdcall x() { return 0; } void const y() {} explicit A() { typedef boost::function<int()> fun_t; fun_t const f(boost::bind(&A::x,this)); } }; ends up with an warning at bind 1>G:\boost\boost_1_37_0\boost/bind.hpp(1643) : warning C4180: qualifier applied to function type has no meaning; ignored 1> G:\boost\boost_1_37_0\boost/bind.hpp(1682) : see reference to class template instantiation 'boost::_bi::add_cref<Pm,I>' being compiled 1> with 1> [ 1> Pm=int (__stdcall Ado::A::* )(void), 1> I=1 1> ] 1> G:\dev\workspace\files\ado\ado_bind.hxx(36) : see reference to class template instantiation 'boost::_bi::dm_result<Pm,A1>' being compiled 1> with 1> [ 1> Pm=int (__stdcall Ado::A::* )(void), 1> A1=Ado::A * 1> ] because the proposed specialization is not choosen by the compiler. Adding an __stdcall to the function signature type in add_cref fixes that problem, but still i do no understand, why the defintion is not like template< class M, class T > struct add_cref< M (__stdcall T::*) (), 1 > { typedef M const& type; }; and of course that fix is only applicable for __stdcall, where specialzations for other calling conventions can easily be generated, like for mem_fn_cc in respect to requested support for calling conventions. Thanks for your help, ILo. compiler : msvc 8.0 library : boost 1.38

2 1

Headers erased after the first building in VC8 of boost 1.38
by Trimoldi, F. (Filippo) 03 Mar '09

03 Mar '09

I generated a Boost.sln solution for VC8 with the new system CMake. ( using this command: cmake -DCMAKE_IS_EXPERIMENTAL=YES_I_KNOW CMakeLists.txt in root directory of the boost ) When I try to build the entire solution all thinks goes good without problem. But only the first time. In fact, at the end of this first building all the headers are erased from the boost the directory. So I cannot make another building and I have to recover the headers file by other ways. Have you got the same problem? This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html

2 1

[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