- Boost - lists.boost.org

GCC 4.3/ia64 build of 1.35 fails on polymorphic_iarchive
by Steve M. Robbins 12 May '08

12 May '08

Bernd, Did you solve the issue reported in [1]? The Debian build for ia64 fails in the same way [2]: In file included from libs/serialization/src/polymorphic_iarchive.cpp:18: ./boost/archive/polymorphic_iarchive.hpp:88: error: 'virtual void boost::archive::polymorphic_iarchive_impl::load(int64_t&)' cannot be overloaded ./boost/archive/polymorphic_iarchive.hpp:84: error: with 'virtual void boost::archive::polymorphic_iarchive_impl::load(long int&)' ./boost/archive/polymorphic_iarchive.hpp:89: error: 'virtual void boost::archive::polymorphic_iarchive_impl::load(uint64_t&)' cannot be overloaded ./boost/archive/polymorphic_iarchive.hpp:85: error: with 'virtual void boost::archive::polymorphic_iarchive_impl::load(long unsigned int&)' ...failed gcc.compile.c++ bin.v2/libs/serialization/build/gcc-4.3.1/release/polymorphic_iarchive.o... [1] http://article.gmane.org/gmane.comp.lib.boost.devel/172455 [2] http://buildd.debian.org/fetch.cgi?&pkg=boost1.35&ver=1.35.0-1&arch=ia64&st… Thanks, -Steve

1 0

[thread] is this reverse_lock class a source of errors?
by vicente.botet 11 May '08

11 May '08

Hi, Consider the following situations: { unique_lock<mutex> lock(smtx); // ... some writing operations { // non locked block reverse_lock< unique_lock<mutex> > rlock(lock); // ... some code not needing the mutex to be locked } // locked again // ... } or { shared_lock<mutex> lock(smtx); // ... some reading operations { // non locked block reverse_lock< shared_lock<mutex> > rlock(lock); // ... some code not needing the mutex to be locked } // locked again // ... } Do you think this usage is souhaitable or is this source of errors? The class reverse_lock can be defined as follows: template <typename Locker> class reverse_lock { BOOST_CONCEPT_ASSERT((MovableLockConcept<Locker>)); public: reverse_lock(Locker& locker) : locker_(locker) /*< Store reference to locker >*/ , tmp_locker_(locker.move()) /*< Move ownership to temporaty locker >*/ , was_locked_(false) { #ifndef BOOST_SYNC_REVERSE_LOCK_DONT_CHECK_OWNERSHIP /*< Define BOOST_SYNC_REVERSE_LOCK_DONT_CHECK_OWNERSHIP if you don't want to check locker ownership >*/ if (tmp_locker_.mutex()==0) { locker_=tmp_locker_.move(); /*< Rollback for coherency purposes >*/ throw lock_error(); } #endif if (tmp_locker_) { /*< ensures it is unlocked >*/ tmp_locker_.unlock(); was_locked_=true; } } ~reverse_lock() { if (was_locked) { tmp_locker_.lock(); } locker_=tmp_locker_.move(); /*< Move ownership to nesting locker >*/ } private: Locker& locker_; Locker tmp_locker_; bool was_locked_; reverse_lock(); }; Comments? _____________________ Vicente Juan Botet Escriba

5 6

[future] Integrating recent future lib into old-ish threadpool lib
by Chris Fairles 10 May '08

10 May '08

There's a nice threadpool library (http://threadpool.sourceforge.net) mentioned on a previous thread that I took a look at and noticed it had a basic future impl. of its own. Given that there's a future library under review, I swapped out the original future impl. in the schedule function, plus added a lazy_schedule (from the examples @ http://braddock.com/~braddock/future/ ) for fun. I replaced everything in future.hpp from the threadpool lib with: /* * Copyright (c) 2005-2007 Philipp Henkel * * Use, modification, and distribution are subject to the * Boost Software License, Version 1.0. (See accompanying file * LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) * * http://threadpool.sourceforge.net * * Chris Fairles, May 2008 - Modified to replace custom future implementation with boost-reviewed version */ #pragma once #include <boost/future/future.hpp> namespace boost { namespace threadpool { template<class Pool, class F> future<typename result_of< F() >::type> schedule(Pool& pool, F const& task) { typedef typename result_of< F() >::type result_type; promise<result_type> prom; pool.schedule(future_wrapper<result_type>(task, prom)); return future<result_type> (prom); } template<class Pool, class F> future<typename result_of< F() >::type> lazy_schedule(Pool& pool, F const& task) { typedef typename result_of< F() >::type result_type; promise<result_type> prom; future<void> guard = prom.get_needed_future(); guard.add_callback(bind(&Pool::schedule, pool, future_wrapper<result_type>(task, prom))); return future<result_type> (prom); } } } // namespace boost::threadpool where #include <boost/future/future.hpp> is the header for the lib under review (and pardon the pragma windowism). I haven't tested it throughly but on msvc9, the most trivial of cases work (including catching exceptions) so YMMV. Ex. int task_int_1() { throw std::exception("task_int_1 exception"); return 1; } int task_int_2() { return 2; } int main() { pool tp; tp.size_controller().resize(2); future<int> result1 = schedule(tp, &task_int_1); future<int> result2 = schedule(tp, &task_int_2); try { int val = result1 + result2; std::cout << "you will never see this value... " << val << std::endl; } catch (std::exception const& ex) } std::cerr << ex.what() << std::endl; } } Something to play around with anyway. Cheers, Chris

1 0

[thread] lockable traits and concepts classes adding proposal
by vicente.botet 10 May '08

10 May '08

Hello boosters , While writtig a synchronization library I have needed some lockable traits and concepts. If you think that these classes are of general use it will be a pleasure for me, if Anthony accepts, to included them on the Boost.Thread library. Otherwise I will left them in my sync library. For the moment all is defined in a sync (as synchronization) namespace and directory but this is without importance. Attached a short introduction as well as the header files. Of course all this is subject to discusion, naming and file structure changes, ... For each one of the mutex in the thread library, we need to * make the mutex inherit from the helper lock_traits_base or * have nested typedefs or * specialize each one of the traits templates As an external library I have do this in a non-intrusive way as for example: template<> struct timed_interface_tag<boost::mutex> { typedef hasnt_timed_interface_tag type; }; template<> struct reentrancy_tag<boost::mutex> { typedef non_recursive_tag type; }; template<> struct category_tag<boost::mutex> { typedef exclusive_lock_tag type; }; template<> struct scope_tag<boost::mutex> { typedef multi_threaded_tag type; }; But if included in the Thread library it will be better to use one of the intrusive methods. I have also other classes that could be of general interest. * A make_..._lockable set of mixin class will make lockable the derived class. It can be used as follows: class X : public make_exclusive_lockable<X, boost::mutex> { } X x; unique_lock<X> lock(x); * a ..._synchronization_family set of classes that can be used as follows: template <class SyncFamily> message_queue; typedef message_queue<thread_synchonization_family> my_mt_message_queue; typedef message_queue<null_synchonization_family> my_st_message_queue; The null_synchonization_family needs a null_mutex and a null_condition classes. * To finish, I'm working on a filter_matching_lockables meta-function which take as parameter a vector of lockables types and will filter the lockables types not satisfying a list of traits. The use shoul be somthing like typedef filter_matching_lockables<vector<boost::mutex, boost::recursive_mutex, ...>, and_<is_exclusive_lock<_>, not_<is_recursive_lock<_> > >::type candidates. and a find_best_lock which choose between the lockables given as parameter the best one following a given criterium. Of course, there is yet a lot of work to complete, add lock concepts, document, tests, document, tests ... between others, that I will be please to do even if included in the Thread library. As you see there is nothing new, neither complex, only some helper classes that currently are missing in boost. Have a good code reading and please let me know what do you think. _____________________ Vicente Juan Botet Escriba

1 0

[result_of][patch] decltype-based implementation
by Daniel Walker 10 May '08

10 May '08

Hello, With all the recent discussion about result_of and now that decltype has started to trickle into compilers, I thought it might be a good time for Boost to provide a result_of along the lines of the typeof-based implementation described in N1454. I've attached a patch to Ticket #862, which does this. http://svn.boost.org/trac/boost/ticket/862 This is an old bug report that apparently got a little mangled during the SVN migration, but I think result_of/lambda compatibility is a familiar problem. My patch fixes the problem of using result_of with lambda on compilers that support decltype. It does not preclude fixes to the problem on C++03 platforms, such as Shunsuke Sogame's Egg and Marco Costalba's multi-signature function, for example. It also makes boost::result_of more compliant with the current C++0x std::result_of described in N2588. My patch differs from N2588 in that std::result_of only supports function call expressions of the form f(x). I read this as precluding support for member function pointers, which are invoked with expressions of the form o->*f(x). My patch reuses the pointer specialization from the current implementation, so that boost::result_of can continue support both. It also may differ from N2588 in terms of the lvalue/rvalue specifications. I'm not sure that I understand this correctly, and I would be grateful if someone would look over it to see if my implementation should be changed for better conformance. The patch also includes updates to the documentation and tests. I tested with msvc 9, gcc 3.4, and gcc 4.3. Thanks for your consideration! Daniel Walker

2 2

[config] Type in config/abi_suffix.hpp file
by Alexei Alexandrov 10 May '08

10 May '08

Hi, there is a minor inconsistency I noted in config/abi_suffix.hpp file. This line # error Header boost/config/abi_prefix.hpp must only be used after boost/config/abi_prefix.hpp should be # error Header boost/config/abi_suffix.hpp must only be used after boost/config/abi_prefix.hpp -- Alexei Alexandrov

2 1

Re: [boost] Profiling template instantiations
by Boris Gubenko 09 May '08

09 May '08

Steven Watanabe wrote: > Ok. It would be great if compilers supported this directly. Just fyi: the cxx compiler has verbose template instantiation mode. On Tru64, for example: x.cpp ----- #include <map> int main() { map<int, int> m; return m.size(); } cosf.zko.hp.com> cxx -V Compaq C++ V7.1-006 for Compaq Tru64 UNIX V5.1B (Rev. 2650) Compiler Driver V7.1-006 (cxx) cxx Driver cosf.zko.hp.com> cxx -ptv -c x.cpp cxx: Info: /usr/lib/cmplrs/cxx/V7.1-006/include/cxx/tree.cc, line 84: automatically instantiating void _RWrwstd::_RWrb_tree<int, std::pair<const int, int> , _RWrwstd::_RWselect1st<std::pair<const int, int> , int> , std::less<int> , std::allocator<std::pair<const int, int> > > ::_RWdeallocate_buffers() void _RWrb_tree<_Key, _Val, _KeyOf, _Comp, _Alloc>::_RWdeallocate_buffers () ------------------------------------------------------^ cxx: Info: /usr/lib/cmplrs/cxx/V7.1-006/include/cxx/tree.cc, line 549: automatically instantiating void _RWrwstd::_RWrb_tree<int, std::pair<const int, int> , _RWrwstd::_RWselect1st<std::pair<const int, int> , int> , std::less<int> , std::allocator<std::pair<const int, int> > > ::_RWerase(_RWrwstd::_RWrb_tree<int, std::pair<const int, int> , _RWrwstd::_RWselect1st<std::pair<const int, int> , int> , std::less<int> , std::allocator<std::pair<const int, int> > > ::_RWrb_tree_node *) void _RWrb_tree<_Key, _Val, _KeyOf, _Comp, _Alloc>::_RWerase (_RWlink_type x) ------------------------------------------------------^ cxx: Info: /usr/lib/cmplrs/cxx/V7.1-006/include/cxx/tree.cc, line 301: automatically instantiating _RWrwstd::_RWrb_tree<int, std::pair<const int, int> , _RWrwstd::_RWselect1st<std::pair<const int, int> , int> , std::less<int> , std::allocator<std::pair<const int, int> > > ::iterator _RWrwstd::_RWrb_tree<int, std::pair<const int, int> , _RWrwstd::_RWselect1st<std::pair<const int, int> , int> , std::less<int> , std::allocator<std::pair<const int, int> > > ::erase(_RWrwstd::_RWrb_tree<int, std::pair<const int, int> , _RWrwstd::_RWselect1st<std::pair<const int, int> , int> , std::less<int> , std::allocator<std::pair<const int, int> > > ::iterator) _RWrb_tree<_Key, _Val, _KeyOf, _Comp, _Alloc>::erase (iterator position) -------------------------------------------------^ cxx: Info: /usr/lib/cmplrs/cxx/V7.1-006/include/cxx/tree.cc, line 565: automatically instantiating _RWrwstd::_RWrb_tree<int, std::pair<const int, int> , _RWrwstd::_RWselect1st<std::pair<const int, int> , int> , std::less<int> , std::allocator<std::pair<const int, int> > > ::iterator _RWrwstd::_RWrb_tree<int, std::pair<const int, int> , _RWrwstd::_RWselect1st<std::pair<const int, int> , int> , std::less<int> , std::allocator<std::pair<const int, int> > > ::erase(_RWrwstd::_RWrb_tree<int, std::pair<const int, int> , _RWrwstd::_RWselect1st<std::pair<const int, int> , int> , std::less<int> , std::allocator<std::pair<const int, int> > > ::iterator, _RWrwstd::_RWrb_tree<int, std::pair<const int, int> , _RWrwstd::_RWselect1st<std::pair<const int, int> , int> , std::less<int> , std::allocator<std::pair<const int, int> > > ::iterator) _RWrb_tree<_Key, _Val, _KeyOf, _Comp, _Alloc>::erase (iterator first, -------------------------------------------------^ cosf.zko.hp.com> ----- Original Message ----- From: <boost(a)lists.boost.org> To: <boost(a)lists.boost.org> Sent: Thursday, May 08, 2008 8:29 PM Subject: Re: [boost] Profiling template instantiations > AMDG > > Simonson, Lucanus J wrote: >> Ingenious, you are automatically inserting a compile time error into >> every basic block of the template code to be profiled, compiling the >> translation unit and counting how many error are generated for each >> template to get a count of how many times the compiler tries (and fails) >> to instantiate the template. >> > > Actually it only generates warnings. Otherwise, the compiler is liable > to stop before it finishes compiling everything. > >> There may be a more direct way to extract this information with VTune >> related profiling features provided in icc. I'll follow up and let you >> know. >> > > Ok. It would be great if compilers supported this directly. > > In Christ, > Steven Watanabe > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

3 3

Re: [boost] Profiling template instantiations
by Boris Gubenko 09 May '08

09 May '08

Steven Watanabe wrote: > I only see function template instantiations, I'm more interested in > class template instantiations because that's where the metaprogramming > is done. Am I missing something? What example in my previous mail shows is names of member functions of class templates being automatically instantiated, along with template arguments they are instantiated on. The output of verbose template instantiation mode serves us well for building common instantiation libraries and this is, probably, why reporting of class template instantiations was never requested. I'm not suggesting cxx as a replacement for your tool. As I said in the previous mail, this is fyi :-) Thanks, Boris ----- Original Message ----- From: <boost(a)lists.boost.org> To: <boost(a)lists.boost.org> Sent: Friday, May 09, 2008 10:38 AM Subject: Re: [boost] Profiling template instantiations > > AMDG > > Boris Gubenko wrote: >> Steven Watanabe wrote: >> >>> Ok. It would be great if compilers supported this directly. >>> >> >> Just fyi: the cxx compiler has verbose template instantiation >> mode. On Tru64, for example: >> >> <snip> >> > > > I only see function template instantiations, I'm more interested in > class template instantiations because that's where the metaprogramming > is done. Am I missing something? > > I'd also like to have all template instantiations, not just those > that are triggered from inside other template instantiations. > (Although this doesn't make a huge difference) > > In Christ, > Steven Watanabe > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

[thread] cache of initialized threads
by vicente.botet 09 May '08

09 May '08

Hi, When we have to create lot of threads dynamicaly it will be better to have a 'pool' of initialized threads (the initialization of a thread takes significant time). Please not that this has nothing to be with the thread_pool class. I'm looking for any work done related to this problem (libraries, emails, ...). Any hints or comments? Thanks in advance Vicente My first thoghts: The cached_threader class interface could be something like class cached_thread; class cached_threader { public: cached_thread launch(boost::function<void()>&); private: friend class cached_thread; void restore(cached_thread); } cached_thread will provide most of the boost::thread operation but some as detach seams not adapted. class cached_thread { friend class cached_threader; cached_threade launch(boost::function<void()>& f); public: cached_thread(); ~cached_thread(); // move support cached_thread(detail::thread_move_t<thread> x); cached_thread& operator=(detail::thread_move_t<cached_thread> x); operator detail::thread_move_t<cached_thread>(); detail::thread_move_t<cached_thread> move(); void swap(cached_thread& x); // ... } The destructor has the responsability to restore the cached_thread to its cached_threader pool. _____________________ Vicente Juan Botet Escriba

5 12

Overloading on concepts
by Anthony Williams 09 May '08

09 May '08

Hi, Does the boost concept checking library support overloading on concepts, so you can have one implementation of an algorithm for random access iterators, and another for bidirectional iterators, for example? Thanks, Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

5 10