September 2010 - Boost - lists.preview.boost.org

Re: [boost] [exception] ostringstream like
by Fabien Castan 19 Oct '10

19 Oct '10

> No, I mean that if you do advanced string manipulation in the exception > itself, you may screw up, adn cause a bad_alloc beign thrown and masking > your own exception. Create an error sentence with some values inside is not really an advanced string manipulation. You can have 2 kinds of errors: bug inside a custom operator<< or a memory problem. There is no particular reason to not have sufficient memory to create an error sentence when throwing something like a logic_error. > Just make your own, informative exception type deriving from logic_error. The problem is not really the kind of exception, but an easy way to create message with boost exception tag system. The idea is to create a new base class for tags allowing to use an ostringstream with tags, which is not possible. typedef ::boost::error_info<struct tag_message,std::ostringstream> message; This little class only remap operator+ call to operator<< on an internal ostringstream. typedef ::boost::error_info<struct tag_message,::boost::error_info_sstream> message; I use it in my code, but I ask here if we can hope to see such things in boost exception. I would prefer to use a standard boost object rather than a custom class.

4 3

New Boostcon sessions uploaded
by Marshall Clow 14 Oct '10

14 Oct '10

Michael Caisse: Using Spirit V2: Qi and Karma http://blip.tv/dashboard/episode/4162161 Stephan T. Lavavej: Data Structure Visualizers in Visual Studio 2010 http://blip.tv/dashboard/episode/4162044 Matt Calabrese, Zachary Laine: Instantiations Must Go! http://blip.tv/dashboard/episode/4161957 Jeremy Siek: Generic Programming And the Boost Graph Library http://blip.tv/dashboard/episode/4161923 More to come (I'm shooting for one session every other day)..... -- Marshall

13 24

[Review] Formal Review: Boost.Ratio
by Anthony Williams 06 Oct '10

06 Oct '10

Hi everyone, The review of Vicente Botet' Ratio library starts October 2nd and lasts until October 11th, 2010, unless an extension occurs. What is it? ======== Portable implementation of the C++0x Standard Library's compile-time rational arithmetic working on C++03 and C++0x compilers. See the current C++0x working draft at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3126.pdf Boost.Ratio provides: * A class template, ratio, for specifying compile time rational constants such as 1/3 of a nanosecond or the number of inches per meter. ratio represents a compile time ratio of compile time constants with support for compile time arithmetic with overflow and division by zero protection * It provides a textual representation of boost::ratio<N, D> in the form of a std::basic_string. Other types such as boost::duration can use these strings to aid in their I/O. This library is header-only and is designed to be generic and useful in a lot of areas of math and numerics C++ programming, in particular it is absolutely needed for the proposed Boost.Chrono and Boost.Stopwatches libraries which are currently in the review queue. Getting the library ============= The latest version of this library may be downloaded from vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=ratio.… SVN: http://svn.boost.org/svn/boost/sandbox/chrono (directories boost/ratio and libs/ratio) and the docs may be viewed here html: http://svn.boost.org/svn/boost/sandbox/chrono/libs/ratio/doc/html/index.html pdf: http://svn.boost.org/svn/boost/sandbox/chrono/libs/ratio/doc/ratio.pdf You can get all these information also (which should avoid some long links) from http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Ratio It is worth noting that the tests included in the zip file are relatively sparse. Vicente has an extensive suite of tests licensed under the LLVM license. He has posted a message on the Boost Developers mailing list regarding the license requirements for tests (See http://thread.gmane.org/gmane.comp.lib.boost.devel/208978) and is awaiting the outcome of that discussion before making the tests available. 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. Anthony Review Manager for the proposed Boost.Ratio library -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

5 6

[fusion] [intro] ADAPT_STRUCT extensions
by Stefan Strasser 04 Oct '10

04 Oct '10

Hi, in the discussion about the library I called "Intro" at the time it has been suggested to use BOOST_FUSION_ADAPT_STRUCT of Boost.Fusion for data member access. based on that I'd like to propose two extensions to ADAPT_STRUCT, which I think are useful beyond my use case: 1) ADAPT_STRUCT can adapt public data members only. with the modifications I uploaded here: http://svn.boost.org/svn/boost/sandbox/intro/boost/fusion/adapted/struct/ all data members can be adapted. for example: class A{ private: friend class fusion::access; int a; }; BOOST_FUSION_ADAPT_STRUCT(A,(int,a) ) 2) adaption of a class including its base class members. for example: struct A{ int a; }; struct B{ int b; }; struct C : A,B{ int c; } BOOST_FUSION_ADAPT_STRUCT(A,(int,a) ) BOOST_FUSION_ADAPT_STRUCT(B,(int,b) ) BOOST_FUSION_ADAPT_DERIVED( C, (A)(B), (int,c) ) an instance of C is now a fusion sequence of size 3. http://svn.boost.org/svn/boost/sandbox/intro/boost/fusion/adapted/struct/ad… private inheritance is supported as above, virtual inheritance is not. I'm not sure if virtual inheritance can be supported.

8 30

Boost.SQL?
by Roland Bock 04 Oct '10

04 Oct '10

Hi, currently I am working on a set of header files which are supposed to make the life of C++ developers easier when in comes to interacting with databases (based on SQL). Goals are: * Stay close to SQL syntax * Do as much type checking as possible * prevent oversights and typical security holes, e.g. by forgetting to escape strings The basic idea is, that given a table definition, it should be possible to * offer a lot of checks at compile time for building a query * make it hard to misinterpret the results Until now, I have been concentrating on table definitions and select statements. Here's a very simplistic example, assuming a table definition "my_table" and a database connection "db": // ------------------------------------------------------------------------- using boost; typedef my_table<> t; typedef sql::select_record<t> record; std::string name("Peter"); ... std::vector<record> records = db.select<record>( sql::where(t::id() > 1000 && t::first_name() == name), sql::order_by(t::priority()(sql::desc)), sql::limit(17)); // the values can be accessed by their name // and are of the correct type, e.g. records.front().first_name_; // is a string records.front().middle_name_; // optional<string> because the table definition says that it can be NULL // In case of a select from more than one table, the values can also be accessed like this records.front().my_table_.first_name; // ------------------------------------------------------------------------- I wonder if there would be interest for such a library in boost.

17 44

[thread] Memory leak in Boost.Thread?
by Denis Arnaud 03 Oct '10

03 Oct '10

Hello, a Fedora user has reported a potential memory leak in Boost.Thread (see https://bugzilla.redhat.com/show_bug.cgi?id=627875 for details), detected with Valgrind in (at least) versions 1.41.0 and 1.44.0. Following is a code snippet allowing to reproduce the issue: ==================================== #include <boost/thread.hpp> void someWork() { double a; for(int i= 0;i< 1000;i++) { a+=log((double)i); } } int main() { for(int i = 0; i< 10; ++i) { boost::thread_group pool; for(int j = 0; j< 100; ++j) { pool.create_thread(someWork); } pool.join_all(); } } ==================================== Then, following is Valgrind's report: ==================================== ==6442== Memcheck, a memory error detector ==6442== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==6442== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==6442== Command: ./boost_leak ==6442== ==6442== ==6442== HEAP SUMMARY: ==6442== in use at exit: 8 bytes in 1 blocks ==6442== total heap usage: 5,967 allocs, 5,966 frees, 701,720 bytes allocated ==6442== ==6442== 8 bytes in 1 blocks are still reachable in loss record 1 of 1 ==6442== at 0x4C2615D: malloc (vg_replace_malloc.c:195) ==6442== by 0x4E3F989: boost::detail::get_once_per_thread_epoch() (in /usr/lib64/libboost_thread-mt.so.1.44.0) ==6442== by 0x4E39923: ??? (in /usr/lib64/libboost_thread-mt.so.1.44.0) ==6442== by 0x4E39BC8: boost::detail::get_current_thread_data() (in /usr/lib64/libboost_thread-mt.so.1.44.0) ==6442== by 0x4E3A528: boost::this_thread::interruption_enabled() (in /usr/lib64/libboost_thread-mt.so.1.44.0) ==6442== by 0x4E3A548: boost::this_thread::disable_interruption::disable_interruption() (in /usr/lib64/libboost_thread-mt.so.1.44.0) ==6442== by 0x404DC4: boost::shared_mutex::lock() (in /tmp/boost_leak) ==6442== by 0x40588D: boost::lock_guard<boost::shared_mutex>::lock_guard(boost::shared_mutex&) (in /tmp/boost_leak) ==6442== by 0x405DB5: boost::thread* boost::thread_group::create_thread<void (*)()>(void (*)()) (in /tmp/boost_leak) ==6442== by 0x403B91: main (in /tmp/boost_leak) ==6442== ==6442== LEAK SUMMARY: ==6442== definitely lost: 0 bytes in 0 blocks ==6442== indirectly lost: 0 bytes in 0 blocks ==6442== possibly lost: 0 bytes in 0 blocks ==6442== still reachable: 8 bytes in 1 blocks ==6442== suppressed: 0 bytes in 0 blocks ==6442== ==6442== For counts of detected and suppressed errors, rerun with: -v ==6442== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6) ==================================== Is that really a memory leak? Kind Regards Denis

3 5

[filesystem] Issue with replace_extension
by cheesy4poofs 02 Oct '10

02 Oct '10

I've recently switched all our code to filesystem v3 and added BOOST_FILESYSTEM_NO_DEPRECATE on our builds for good measure. One of the changes I had to fix was our use of change_extension(), which was modified to use the replace_extension() method. However, some of our code started failing and I tracked it down to this example: boost::filesystem::path p("C:\\database\\test\\filename"); p.replace_extension(".db"); std::cout << p.string() << std::endl; // OUTPUT - C:\database\test\filename.db p = "C:\\database.1\\test\\filename"; p.replace_extension(".db"); // bug? std::cout << p.string() << std::endl; // OUTPUT - C:\database.db As you can see, in the second example, it truncates the path and assumes the directory name "database.1" has the extension that needs replacing. change_extension() did not behave this way. Is this the expected behavior? Thanks, Scott

2 1

[1.43.0] [variant] Compilation errors when swapping variant type objects
by Adam Badura 01 Oct '10

01 Oct '10

We are using Boost 1.43.0 (we tried to move to 1.44.0 but there were some problems which I reported some time ago) in Visual Studio 2010. And there are some compilation problems when variant type objects are swapped. This does not affect all variant types but I didn't figured out what are the exact conditions (however I guess it is likely something with namespaces and templates). Following code demonstrates the issue: ---------------------------------------- #include <cstdlib> #include <list> #include <boost/variant.hpp> int main() { typedef boost::variant< std::list< int >::iterator > variant_type; variant_type v; variant_type().swap( v ); return EXIT_SUCCESS; } ---------------------------------------- compilation fails with following message: ---------------------------------------- 1>d:\libraries\boost_1_43_0\boost\variant\detail\move.hpp(155): error C2668: 'boost::detail::variant::detail::move_swap::swap' : ambiguous call to overloaded function 1> d:\libraries\boost_1_43_0\boost\variant\detail\move.hpp(141): could be 'void boost::detail::variant::detail::move_swap::swap<T>(T &,T &)' 1> with 1> [ 1> T=T0 1> ] 1> c:\program files\microsoft visual studio 10.0\vc\include\utility(100): or 'void std::swap<T>(_Ty &,_Ty &)' [found using argument-dependent lookup] 1> with 1> [ 1> T=T0, 1> _Ty=T0 1> ] 1> while trying to match the argument list '(T0, T0)' 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(698) : see reference to function template instantiation 'void boost::detail::variant::move_swap<T>(T &,T &)' being compiled 1> with 1> [ 1> T=T0 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(825) : see reference to function template instantiation 'void boost::detail::variant::swap_with<Variant>::operator ()<T>(T &) const' being compiled 1> with 1> [ 1> Variant=boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>, 1> T=T0 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\detail\visitation_impl.hpp(141) : see reference to function template instantiation 'void boost::detail::variant::invoke_visitor<Visitor>::internal_visit<T>(T &,int)' being compiled 1> with 1> [ 1> Visitor=boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>>, 1> T=T0 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\detail\visitation_impl.hpp(169) : see reference to function template instantiation 'void boost::detail::variant::visitation_impl_invoke_impl<Visitor,VoidPtrCV,T>(int,Visitor &,VoidPtrCV,T *,boost::mpl::false_)' being compiled 1> with 1> [ 1> Visitor=boost::detail::variant::invoke_visitor<boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>>>, 1> VoidPtrCV=void *, 1> T=T0 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\detail\visitation_impl.hpp(252) : see reference to function template instantiation 'void boost::detail::variant::visitation_impl_invoke<Visitor,VoidPtrCV,T0,NoBackupFlag>(int,Visitor &,VoidPtrCV,T *,NoBackupFlag,int)' being compiled 1> with 1> [ 1> Visitor=boost::detail::variant::invoke_visitor<boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>>>, 1> VoidPtrCV=void *, 1> NoBackupFlag=boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>::has_fallback_type_, 1> T=T0 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(1769) : see reference to function template instantiation 'void boost::detail::variant::visitation_impl<first_which,first_step,Visitor,VoidPtrCV,boost::variant<T0_>::has_fallback_type_>(const int,const int,Visitor &,VoidPtrCV,boost::mpl::false_,NoBackupFlag,Which *,step0 *)' being compiled 1> with 1> [ 1> Visitor=boost::detail::variant::invoke_visitor<boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>>>, 1> VoidPtrCV=void *, 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>>, 1> NoBackupFlag=boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>::has_fallback_type_, 1> Which=first_which, 1> step0=first_step 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(1780) : see reference to function template instantiation 'void boost::variant<T0_>::internal_apply_visitor_impl<Visitor,void*>(int,int,Visitor &,VoidPtrCV)' being compiled 1> with 1> [ 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>>, 1> Visitor=boost::detail::variant::invoke_visitor<boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>>>, 1> VoidPtrCV=void * 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(1803) : see reference to function template instantiation 'void boost::variant<T0_>::internal_apply_visitor<boost::detail::variant::invoke_visitor<Visitor>>(boost::detail::variant::invoke_visitor<Visitor> &)' being compiled 1> with 1> [ 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>>, 1> Visitor=boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>> 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(1637) : see reference to function template instantiation 'void boost::variant<T0_>::apply_visitor<boost::detail::variant::swap_with<Variant>>(Visitor &)' being compiled 1> with 1> [ 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>>, 1> Variant=boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>, 1> Visitor=boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>> 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(1631) : while compiling class template member function 'void boost::variant<T0_>::swap(boost::variant<T0_> &)' 1> with 1> [ 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>> 1> ] 1> d:\test\simple\simple.cpp(10) : see reference to class template instantiation 'boost::variant<T0_>' being compiled 1> with 1> [ 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>> 1> ] ---------------------------------------- Adam Badura

2 2

Potential scoped_ptr improvement
by David Abrahams 30 Sep '10

30 Sep '10

The incantation scoped_ptr<Base> x( new Derived ); will succeed and produce undefined behavior upon x's destruction unless Derived has a trivial or virtual d'tor. It would be pretty easy to prevent something like that from compiling when has_virtual_destructor<Base>::value is false. Thoughts? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 2

[btree] Library working with more compilers and standard libraries
by Beman Dawes 30 Sep '10

30 Sep '10

* VC++ 10 and MinGW/gcc 4.5 are my primary platforms, and the tests continue to pass on those. Some of the tests have been beefed up, too. * The Btree library now passes tests with Cygwin/gcc 4.3. That was a bug in my POSIX implementation code that is now fixed. * VC++ 9 is working OK in release mode. There is a bug in some debug mode code in the standard library <algorithm> header's lower_bound and upper_bound functions. I'm not sure how to deal with that. Maybe supply lower_bound/upper_bound implementations, and switch to them when needed. * I'm about to start a round of tests on Linux. --Beman

3 4

Re: [boost] [guidelines] why template errors suck
by Andrzej Krzemienski 29 Sep '10

29 Sep '10

> > > Well, I believe I got it wrong. It is concept maps where the specializtion > > > is to tke plce. It should read: > > > > > > explicit concept< typename T > IntOrPair > "explicit concepts" were never part of any accepted proposal ;-) > > { > > int sum_ints_impl( T const& ); > > } > > > > concept_map IntOrPair<int> > > { > > int sum_ints_impl( int const& i ) { return i; } > > } > > > > template< IntOrPair type1, IntOrPair type2 > > > concept_map IntOrPair< std::pair<type1, type2> > > > { > > int sum_ints_impl( std::pair<First, Second> const& p ) { > > return sum_ints_impl(p.first) + sum_ints_impl(p.second); > > } > > } > > > > template<IntOrPair T> > > int sum_ints( T const & t ) > > { > > return IntOrPair::sum_ints_impl( t ); > > } > I think what you wrote is equivalent to what I posted in > http://permalink.gmane.org/gmane.comp.lib.boost.devel/209012 > However, as I noted in that message, trying to constrain something to > be either an Int or a Pair is really against the spirit of GP. I understand. On the other hand, even though concepts were designed to support GP, once they are designed it would be interesting to see how they can be used to do other thing, and what other possibilities they enable. Regards, &rzej

2 1

Advice sought on memory allocation latency reduction C++ standard proposal
by Niall Douglas 29 Sep '10

29 Sep '10

Dear Boost Devs, I am hoping to gain feedback on an ISO C++ standard library proposal I hope to submit. It consists of a rationale (http://mallocv2.wordpress.com/) which shows how growth in RAM capacity is exponentially outgrowing the growth in RAM access speed. The consequences are profound: computer software which has always been written under the assumption of scarcity of RAM capacity will need to be retargeted to assume the scarcity of RAM access speed instead. I appreciate that Boost is not the C++ standard library, however I have asked this on comp.std.c++ and received no reply at all. The proposal comes in two parts: (i) The C proposal (http://mallocv2.wordpress.com/the-c-proposal-text/) which extends the classic 1979 malloc API to enable realloc() to speculatively attempt in-place allocation resizing and (ii) the C++ proposal (http://mallocv2.wordpress.com/the-cpp-proposal-text/) which extends std::allocator<> with batch allocation and deallocation member functions along with a reallocate() member function. These work much as expected and are intended for STL implementations - I have given a sample std::vector<>::reserve() implementation for the Dinkumware STL which attempts an in-place extension before performing a move construction of the vector contents. I am going to guess that these member functions will be fairly uncontroversial - reallocate() in particular has been in the SGI STL for a while, though in an unhelpful form which is basically a realloc() wrapper. What I think will likely be much more controversial are the new std namespace functions: template<class T, class allocator=allocator<T>, class... Args> typename allocator<T>::pointer New(Args&&... args); template<class T, class allocator=allocator<T>, class... Args> typename allocator<T>::pointer NewA(size_t n, Args&&... args); template<class T, class allocator=allocator<T> > void Delete(typename allocator<T>::const_pointer p); template<class T, class allocator=allocator<T> > void DeleteA(typename allocator<T>::const_pointer p); These parallel global operators new and delete except of course that they are standard functions and take a std::allocator<> type with which they perform the allocation and deallocation. The biggest danger here obviously enough is the chance of collision with any New() or Delete() defined by application code as the overloading and type specialisation problems (thanks to the unhelpful syntax) of operators new and delete are well known. The second biggest danger is the perhaps confusing duplication of functionality, though of course std::New() and std::Delete() are intended as a superset of global operators new and delete. I would appreciate any feedback, and in case you don't think discussion of this topic is appropriate here I will cross post this email to comp.std.c++. You can reply there instead if you wish. My thanks in advance for your time and consideration. Niall Douglas -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909.

3 2

Floating point truncation bug in qi::float_
by Henry Tan 29 Sep '10

29 Sep '10

Hi I am using boost 1.4.1 Spirit::Qi. I think we have a floating point truncation bug in the qi::float_ parser. I attached a simple program to repro the bug. Below are some examples of an input floating point gets truncated (=>) by the qi::float_: 12312321421421 => 12312321720320.000000 123123214 => 123123216.000000 123233.4124 => 123233.406250 I don't see the same issue with the qi::double_. Wondering if this is a known issue? Regards, HTan

5 4

How to cast _1 ?
by Henry Tan 29 Sep '10

29 Sep '10

I want to cast a value of _1 to a _val of a different type. How do I do that? I tried using static_cast_, it does not compile for me. rule<UInt8Iterator, UInt32()> MyRule; ... MyRule = (long_ | float_) [_val = static_cast_<UInt32>(_1)] Any help is appreciated Regards, Henry

2 1

Re: [boost] [asio] Question regarding io_service.post() and pool of threads
by Tan, Tom (Shanghai) 29 Sep '10

29 Sep '10

-----Original Message----- Date: Tue, 28 Sep 2010 11:18:22 +0800 From: Romain CHANU <romainchanu(a)gmail.com> To: boost(a)lists.boost.org Subject: [boost] [asio] Question regarding io_service.post() and pool of threads > >Extracted from Boost Asio reference: "The >io_service<http://www.boost.org/doc/libs/1_44_0/doc/html/boost_asio/ref >erence/io_service.html> >guarantees >that the handler will only be called in a thread in which the run(), >run_one (), poll() or poll_one() member functions is currently being invoked." > >For my understanding, since there is a pool of threads, a handler can >run concurrently in different threads, even though we are using >io_service.post(). > >Is that correct? My concern here is about the need or not to lock the >data accessed by the handler. > My understanding is that, it's another way to say that those calls won't create an additional thread while calling the completion handler having been registered by io_service.post(). Therefore, if io_service.run() itself is running in n threads, it's guaranteed all the registered completion handler will be invoked in at most n threads at random order, since there are only n threads in total . -Tom

2 1

Fwd: [test] crash with the following test
by Felipe Magno de Almeida 28 Sep '10

28 Sep '10

Hello, Since I couldn't solve the problem in boost-users list I'm forwarding here. ---------- Forwarded message ---------- From: Felipe Magno de Almeida <felipe.m.almeida(a)gmail.com> Date: Wed, Sep 22, 2010 at 2:07 PM Subject: [test] crash with the following test To: boost-users(a)lists.boost.org With boost 1.44.0 (the same happens with 1.43) the following test causes a crash in framework.ipp:388 with a dereference of a NULL pointer. The test_unit* res returns NULL from s_frk_impl().m_test_units[id] where id is 1. id is equal to 1 because when unit_test::framework::run is ran, id is INV_TEST_UNIT_ID is passed to it. Then in framework.ipp:399 if id == INV_TEST_UNIT_ID id is assigned the value in master_test_suite().p_id which is 1. I've verified that when master_test_suite is constructed it assigns INV_TEST_UNIT_ID to p_id, so I'm lost why this is 1 here. Then, back in framework.ipp:386 s_frk_impl().m_test_units there's only one element in the map and the id is 65535 and not one. -- test.cpp -- #define BOOST_TEST_MODULE parse_empty_import_documents #include <boost/test/included/unit_test.hpp> BOOST_AUTO_TEST_CASE (parse_empty_import_documents) { } -- test.cpp -- Any help would be appreciated. -- Felipe Magno de Almeida

2 5

Re: [boost] [guidelines] why template errors suck
by Andrzej Krzemienski 28 Sep '10

28 Sep '10

> > I think so far I have failed to make my use case sufficiently clear, so > > I'll simplify and try to follow the Process. Take the following simple > > algorithm sum_ints: > > > > template<class First, class Second> > > int sum_ints_impl( std::pair<First, Second> const & p ) > > { > > return sum_ints_impl(p.first) + sum_ints_impl(p.second); > > } > > > > int sum_ints_impl( int i ) > > { > > return i; > > } > > template<class T> > > int sum_ints( T const & t ) > > { > > return sum_ints_impl( t ); > > } > > Hi, how about the below. Concept IntOrPair is empty because you do not require it to have any operations. Keyword "explicit" indicates that we do not want it to be an auto-concept: concept map is > always required. The second concept_map implements the recursion. > > Regards, > &rzej > > explicit concept< typename T > IntOrPair > { > } > > concept_map IntOrPair<int> > { > } > > template< IntOrPair type1, IntOrPair type2 > > concept_map IntOrPair< std::pair<type1, type2> > > { > } > > template<IntOrPair First, IntOrPair Second> > int sum_ints_impl( std::pair<First, Second> const & p ) > { > return sum_ints_impl(p.first) + sum_ints_impl(p.second); > } > > int sum_ints_impl( int i ) > { > return i; > } > > template<IntOrPair T> > int sum_ints( T const & t ) > { > return sum_ints_impl( t ); > } Well, I believe I got it wrong. It is concept maps where the specializtion is to tke plce. It should read: explicit concept< typename T > IntOrPair { int sum_ints_impl( T const& ); } concept_map IntOrPair<int> { int sum_ints_impl( int const& i ) { return i; } } template< IntOrPair type1, IntOrPair type2 > concept_map IntOrPair< std::pair<type1, type2> > { int sum_ints_impl( std::pair<First, Second> const& p ) { return sum_ints_impl(p.first) + sum_ints_impl(p.second); } } template<IntOrPair T> int sum_ints( T const & t ) { return IntOrPair::sum_ints_impl( t ); } Regrds, &rzej

2 1

New library ( countertree: Binary trees with access by position like the vectors)
by Francisco José Tapia 28 Sep '10

28 Sep '10

Is there any interest in a library implementing counter trees, which permit us to access to the elements by the position, as in the same way than a vector.The insertion, deletion and access to elements are operations O(log N). The iterator and const_iterator are random access iterators in the same way than the STL vector::iterator and STL vector::const_iterator. These iterators and const_iterators have a function pos() which provide the position in the tree. The first class implemented is vector_tree wich has the full interface of the STL vector and STL deque. When the information stored in the vector_tree is sorted, we can build the new classes boost::set, boost::multiset, boost::map and boost::multimap. These clases have the full interface of the STL set , multiset, map and multimap, plus a function which permit to access to the elements of the set, map... by the position. The iterators of this data stuctures are random access, and have a function to take the position of the element pointed by the iterator. The performance of these data stuctures is similar to the STL set, multiset, map and multimap You can find the documentation, the code and the test programs in : http://www.boostpro.com/vault/index.php?action=downloadfile&filename=counte… The compilers used for to check are GCC 4.5 ( 32 and 64 bits) and Visual Studio 2008 Thanks Francisco Tapia fjtapia(a)gmail.com

6 6

Re: [boost] [guidelines] why template errors suck
by Andrzej Krzemienski 28 Sep '10

28 Sep '10

> I think so far I have failed to make my use case sufficiently clear, so > I'll simplify and try to follow the Process. Take the following simple > algorithm sum_ints: > > template<class First, class Second> > int sum_ints_impl( std::pair<First, Second> const & p ) > { > return sum_ints_impl(p.first) + sum_ints_impl(p.second); > } > > int sum_ints_impl( int i ) > { > return i; > } > template<class T> > int sum_ints( T const & t ) > { > return sum_ints_impl( t ); > } Hi, how about the below. Concept IntOrPair is empty because you do not require it to have any operations. Keyword "explicit" indicates that we do not want it to be an auto-concept: concept map is always required. The second concept_map implements the recursion. Regards, &rzej explicit concept< typename T > IntOrPair { } concept_map IntOrPair<int> { } template< IntOrPair type1, IntOrPair type2 > concept_map IntOrPair< std::pair<type1, type2> > { } template<IntOrPair First, IntOrPair Second> int sum_ints_impl( std::pair<First, Second> const & p ) { return sum_ints_impl(p.first) + sum_ints_impl(p.second); } int sum_ints_impl( int i ) { return i; } template<IntOrPair T> int sum_ints( T const & t ) { return sum_ints_impl( t ); }

1 0

Interest in specialized types
by Henning Basold 28 Sep '10

28 Sep '10

Hello, in http://permalink.gmane.org/gmane.comp.lib.boost.devel/207794 Robert Ramey talked about wrapping some POD to increase type safety. Some time ago I used something similar to ensure that misuse of values can be found by the compiler. So I think that is something that can be generalized. The concept is to wrap a type into a class and restrict the interface. This ensures that values from one context (e.g. an id) can't be used in another context (e.g. adding of number or as an id for other objects). Attached is a very simple implementation where the needed concepts can be specified as parameter. To distinguish for example between different id types also a tag type can be specified. Do you think this might be a useful utility? Or is there something similar already available? I've searched the vault but did not find anything. Regards Henning

5 11

Recall: Boost Digest, Vol 3047, Issue 1
by Tan, Tom (Shanghai) 28 Sep '10

28 Sep '10

Tan, Tom (Shanghai) would like to recall the message, "Boost Digest, Vol 3047, Issue 1".

1 0

[asio] Question regarding io_service.post() and pool of threads
by Romain CHANU 28 Sep '10

28 Sep '10

Hi, I was looking at this website where the guy gives an interesting example about the use of a pool of threads and io_service.post(): http://mostlycoding.blogspot.com/2009/05/asio-library-has-been-immensely-he… However, something confuses me a bit, cf. the website "In just a bunch of lines of code we have a thread pool executing any arbitrary task whenever one thread is available. No need to address the usual multi-threading issues with concurrent jobs sharing few resources: just post what you need and let io_service take care of it!" Extracted from Boost Asio reference: "The io_service<http://www.boost.org/doc/libs/1_44_0/doc/html/boost_asio/reference/io_servi…> guarantees that the handler will only be called in a thread in which the run(), run_one (), poll() or poll_one() member functions is currently being invoked." For my understanding, since there is a pool of threads, a handler can run concurrently in different threads, even though we are using io_service.post(). Is that correct? My concern here is about the need or not to lock the data accessed by the handler. Thank you. Regards, Romain

3 3

Missing file
by Belcourt, Kenneth 28 Sep '10

28 Sep '10

Tests failed for this missing file. error: Unable to find file or target named error: '../no_limits_lowest_pass.cpp' error: referred from project at error: '/scratch/boost/boost/libs/config/test/all'

2 1

Re: [boost] [B-tree] Continuing development
by Brian Wood 27 Sep '10

27 Sep '10

OvermindDL1: <woodbrian77(a)gmail.com> wrote: >> >> Just fyi, I've been experimenting with a similar string -- >> http://webEbenezer.net/misc/lil_string.hh . >> >> If an operation would result in a string with length more than 255, >> an exception is thrown. ?This allows the length of the string to be >> marshalled with one byte. ?As you mention this limitation is not a >> problem in many circumstances. ?I'd quibble a little with it not being >> suitable for demanding applications. ?I think it is fine to use it in that >> context, but that you might need to also use other string classes. > > Why not use a compressed uint type? Google's Protocol Buffers > compressed uint compresses an uint just fine, below 128 will be >represented in one byte, etc..., it works very simply, by just having > the MSB be a marker indicating the last byte of the integer if it is > zero, thus it is base 128 instead of base 256 per byte, so as an > example: > hex -> compressed bits > 0 -> 0000 0000 > 1 -> 0000 0001 > 300 -> 1010 1100 0000 0010 > And so forth, and if you have looked in the protocol buffer source it > decodes each byte very quickly and efficiently. So if you are worried > about space, you could use this (especially since I have many use > cases where strings would exceed 255 characters, and we need a > 'bytestream' type or so too). I've thought about doing that and I'm using that technique in one place in my library. The only thing I can say is I like the documentation effect that the name lil_string has. I don't claim what you suggest is a bad idea, but at the moment I'm happy with what I have. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net (651) 251-9384

1 0

[Atomic] Confusion about Atomicaty of atomic::exchange.
by cexer 27 Sep '10

27 Sep '10

Hey guys, I am very interested in Boost.Atomic library, but when I went deeply into the source code, I found there are mysteries that I can not fullly understand, for example, the implementation of atomic::exchange, list its implementation code (see. /atomic/builderhpp, line 47.) as follow : integral_type exchange(integral_type replacement, memory_order order=memory_order_seq_cst) volatile { integral_type o=load(memory_order_relaxed); // A do {} while(!compare_exchange_weak(o, replacement, order, memory_order_relaxed)); // B return o; } From my view, although atomic::load and atomic::compare_exchnage_weak are both atomic operations, the atomicity of atomic::exchnage is not guaranteed，take this illustrative code-snippet for example : atomic<int> i( 1 ); thread1 i.exchange( 100 ); thread2 i.exchange( 200 ); // C To help explanation, in the atomic::exchange method and the above code-snippet, I lable corresponding code fragments as A, B, C. Assume that thread1 is completed running A, but has not arrive B yet, at this moment values of i and o ( o is the temporary variable in atomic::exchange method, see source code of atomic::exchnage above. ) are: o == 1 i == 1 Since the atomic::exchange is not locked, and calling to atomic::load using memory order of memory_order_relaxed, under this circumstance, atomic::exchnage is not prevent from calling from more than one threads, so these is possibility that thread2 could call atomic::exchange (like the code C above) between A and B, after thread2 completed C, the value of i is changed, values of i and o values are now: o == 1 i == 200 Then thread1 arrives code B, because at this moment o! = i, calling to compare_exchnage_weak will fail, atomic::exchange them will went into infinite loop, this is terrible. I know I must missing something here, so I posting here, expecting that someone could please remind me a little bit?

2 1