- Boost - lists.boost.org

[ptr_container] Failures for ptr_set and ptr_unordered_set on Intel, Acc, and Cxx
by Markus Schöpflin 12 Jun '08

12 Jun '08

Hello, currently these tests fail with "../boost/ptr_container/ptr_set_adapter.hpp", line 362: error #2309: more than one instance of constructor "boost::ptr_container_detail::ptr_set_adapter_base<Key, VoidPtrSet, CloneAllocator, Ordered>::ptr_set_adapter_base [with Key=Base, VoidPtrSet=std::set<void *, boost::void_ptr_indirect_fun<std::less<Base>, Base, Base>, std::allocator<void *>>, CloneAllocator=boost::heap_clone_allocator, Ordered=true]" matches the argument list: function template "boost::ptr_container_detail::ptr_set_adapter_base<Key, VoidPtrSet, CloneAllocator, Ordered>::ptr_set_adapter_base(const Compare &, const Allocator &) [with Key=Base, VoidPtrSet=std::set<void *, boost::void_ptr_indirect_fun<std::less<Base>, Base, Base>, std::allocator<void *>>, CloneAllocator=boost::heap_clone_allocator, Ordered=true]" function template "boost::ptr_container_detail::ptr_set_adapter_base<Key, VoidPtrSet, CloneAllocator, Ordered>::ptr_set_adapter_base(InputIterator, InputIterator) [with Key=Base, VoidPtrSet=std::set<void *, boost::void_ptr_indirect_fun<std::less<Base>, Base, Base>, std::allocator<void *>>, CloneAllocator=boost::heap_clone_allocator, Ordered=true]" argument types are: (boost::void_ptr_iterator<__rw::__rw_tree_iter<void *, ptrdiff_t, void *const *, void *const &, __rw::__rw_rb_tree_node<std::allocator<void *>, void *, void *, __rw::__ident<void *, void *>>>, Base>, boost::void_ptr_iterator<__rw::__rw_tree_iter<void *, ptrdiff_t, void *const *, void *const &, __rw::__rw_rb_tree_node<std::allocator<void *>, void *, void *, __rw::__ident<void *, void *>>>, Base>) : base_type( first, last ) The compilers has difficulties choosing between: template< class Compare, class Allocator > ptr_set_adapter_base( const Compare& comp, const Allocator& a ) and template< class InputIterator > ptr_set_adapter_base( InputIterator first, InputIterator last ) Interestingly, if I just remove the following constructors, these tests pass for me on Cxx, and no other failures are introduced. template< class Compare, class Allocator > ptr_set_adapter_base( const Compare& comp, const Allocator& a ) template< class Compare, class Allocator > associative_ptr_container( const Compare& comp, const Allocator& a ) So are these constructors needed at all? Markus

2 2

[thread_safe_signals] reviving boost::trackable?
by Frank Mori Hess 12 Jun '08

12 Jun '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It's occurred to me that thread-safe automatic connection management for signal/slot connections made in an object's constructor to one of its member functions could be accomplished by using a boost::trackable class that looks like class trackable: public enable_shared_from_this<trackable> { //... }; Above, I'm only requiring the "classic" enable_shared_from_this functionality, no special support for shared_from_this in constructors, etc. You would derive from trackable, visit_each would discover it inside bind objects, and its destructor would disconnect its associated connections, similar to how the current signals library works. It would do a bit more though. When the signal is invoked, it would: 1) check that the connection has not been disconnected. If not, it calls shared_from_this() to obtain a shared_ptr which can be used for connection tracking in the usual thread_safe_signals way. Calling shared_from_this can be made safe since the trackable destructor (which disconnects) will be called before the enable_shared_from_this destructor. 2) if the shared_ptr from shared_from_this is empty, that means the trackable object is either in the process of being destroyed, or hasn't been passed to an external shared_ptr owner yet. In either case, the slot is skipped by the signal invocation. However, there is a downside to this and other schemes where the signal/slot connection is made in the constructor but blocked until the object is passed to an external shared_ptr. In a common use case, an observer will connect to an observed object's signal and then manually query the observed object once to get its initial state. It can then rely on the signal to keep in sync with any changes the observed object undergoes. If the signal is blocked until the observer is owned by an external shared_ptr, it raises the possibility of the observer getting out of sync with the observed, since a signal could occur and be missed after the manual query of the observed object's initial state. So, doing all the connection setup in a postconstructor still seems preferable. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIUS7c5vihyNWuA4URAhPIAKC40cK1kgX9o7aPYILBaHZu3jwZhQCfYFjw o/drv0EOsHqvEt+7exy/PDo= =Lj6m -----END PGP SIGNATURE-----

1 0

Re: [boost] [circular_buffer] why is there no reserve(size_type)?
by Jan Gaspar 12 Jun '08

12 Jun '08

> no, but there are overlaps in functionality/use-cases and not having > reserve makes it harder to write generic code that accepts either type. list and deqeue functionality/use-cases overlap with vector too but they do not have reserve as well ... But if you really need it you can implement it by yourself, don't forget to document it properly and add unit tests. Ideally if you can send me a patch. Jan Send instant messages to your online friends http://uk.messenger.yahoo.com

1 0

Re: [boost] [circular_buffer] why is there no reserve(size_type)?
by Jan Gaspar 12 Jun '08

12 Jun '08

Sorry I don't have time to do this. Anyway IMO implementing reserve would give an impression that the capacity is not fixed and increases as you put elements into the circular buffer. And at last circular buffer is not a vector. ----- Original Message ---- From: Thorsten Ottosen <thorsten.ottosen(a)dezide.com> To: boost(a)lists.boost.org Sent: Wednesday, 11 June, 2008 9:49:29 PM Subject: Re: [boost] [circular_buffer] why is there no reserve(size_type)? Jan Gaspar skrev: > because: > 1) it's behaviour is slightly different from the standard - you can increase but also decrease the capaciry of the container; decreasing of the capacity is not supported by reserve() > 2) the word capacity is used all over the documentation of the circular buffer. I think set_capacity expresses better what the method does. So the function is slightly different from the one in std::vector :-) Having a reserve() won't hurt ... in fact, it will make it easier to write code that works for both vector and circular_buffer. -Thorsten _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost __________________________________________________________ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

2 1

interest in thread-pool library
by Oliver Kowalke 12 Jun '08

12 Jun '08

Hi, I don't know why but my previous email from yesterday did not occur on the mailing list? I've uploaded two versions of my threadpool library - maybe you are interressted in. It provides thread management, queueing and scheduling policies as well chaining of tasks and lazy processing of submited tasks (== processed only if requested). version 1: submit returens a future (Braddock future library) whic his cancelable (remove pending task from queue) version 2: submit returns a task object which provides a interrupt memebr function (task can be interrupted if its is running and cooperative) Both libraries are available at Boost.Vault / Concurrent Programming. so long, Oliver -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

1 0

Boost build mailing list moderation?
by Emil Dotchevski 12 Jun '08

12 Jun '08

Recently I subscribed and made 2 posts to the boost build mailing list, and got the standard reply that they need to be reviewed by the moderators and that they will either be posted or I'll get a notification that there is a problem. I got no notification but I don't see my questions appearing in the boost build mailing list. My 2 posts have the following subject lines: - Using boost build on linux - Testing problem with Boost Build Any ideas? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

2 1

Boost exceptions under Windows
by Zack S 11 Jun '08

11 Jun '08

Hi folks, Why doesn't the Boost code, in the cases where it needs to throw an exception under Windows, offer the option to display a dialog window? Something like a #define'able option could be useful. Zack

10 17

Re: [boost] [circular_buffer] why is there no reserve(size_type)?
by Jan Gaspar 11 Jun '08

11 Jun '08

because: 1) it's behaviour is slightly different from the standard - you can increase but also decrease the capaciry of the container; decreasing of the capacity is not supported by reserve() 2) the word capacity is used all over the documentation of the circular buffer. I think set_capacity expresses better what the method does. Jan ----- Original Message ---- From: Steven Watanabe <watanabesj(a)gmail.com> To: boost(a)lists.boost.org Sent: Wednesday, 11 June, 2008 3:49:21 PM Subject: Re: [boost] [circular_buffer] why is there no reserve(size_type)? AMDG Jan Gaspar wrote: > it is called set_capacity(capacity_type) > Why is this different from the standard library name? In Christ, Steven Watanabe _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost __________________________________________________________ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

2 1

Building boost 1.35 with boost.serialization 1.36
by Chris Hamilton 11 Jun '08

11 Jun '08

I require a few of the new features introduced in Boost.Serialization 1.36, namely the support of serialization across multiple shared libraries and multi-threaded support. The Serialization library itself doesn't build cleanly, but adding a missing #include in one of the headers solves that for me. However, I now get errors when building the MPI library: gcc.compile.c++ bin.v2/libs/mpi/build/gcc-3.4.6/release/threading-multi/packed_iarchive.o In file included from libs/mpi/src/packed_iarchive.cpp:11: ./boost/archive/impl/archive_pointer_oserializer.ipp:27: error: redefinition of `class boost::archive::detail::<unnamed>::serializer_map<Archive>' ./boost/archive/impl/archive_pointer_iserializer.ipp:27: error: previous definition of `class boost::archive::detail::<unnamed>::serializer_map<Archive>' "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -fPIC -pthread -DBOOST_ALL_NO_LIB=1 -DBOOST_MPI_DYN_LINK=1 -DBOOST_MPI_SOURCE=1 -DNDEBUG -I"." -I"/opt/lam/gnu/include" -c -o "bin.v2/libs/mpi/build/gcc-3.4.6/release/threading-multi/packed_iarchive.o" "libs/mpi/src/packed_iarchive.cpp" ...failed gcc.compile.c++ bin.v2/libs/mpi/build/gcc-3.4.6/release/threading-multi/packed_iarchive.o... ...removing bin.v2/libs/mpi/build/gcc-3.4.6/release/threading-multi/packed_iarchive.o gcc.compile.c++ bin.v2/libs/mpi/build/gcc-3.4.6/release/threading-multi/packed_oarchive.o gcc.compile.c++ bin.v2/libs/mpi/build/gcc-3.4.6/release/threading-multi/packed_skeleton_iarchive.o In file included from libs/mpi/src/packed_skeleton_iarchive.cpp:11: ./boost/archive/impl/archive_pointer_oserializer.ipp:27: error: redefinition of `class boost::archive::detail::<unnamed>::serializer_map<Archive>' ./boost/archive/impl/archive_pointer_iserializer.ipp:27: error: previous definition of `class boost::archive::detail::<unnamed>::serializer_map<Archive>' "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -fPIC -pthread -DBOOST_ALL_NO_LIB=1 -DBOOST_MPI_DYN_LINK=1 -DBOOST_MPI_SOURCE=1 -DNDEBUG -I"." -I"/opt/lam/gnu/include" -c -o "bin.v2/libs/mpi/build/gcc-3.4.6/release/threading-multi/packed_skeleton_iarchive.o" "libs/mpi/src/packed_skeleton_iarchive.cpp" ...failed gcc.compile.c++ bin.v2/libs/mpi/build/gcc-3.4.6/release/threading-multi/packed_skeleton_iarchive.o... ...removing bin.v2/libs/mpi/build/gcc-3.4.6/release/threading-multi/packed_skeleton_iarchive.o gcc.compile.c++ bin.v2/libs/mpi/build/gcc-3.4.6/release/threading-multi/packed_skeleton_oarchive.o ...skipped <pbin.v2/libs/mpi/build/gcc-3.4.6/release/threading-multi>libboost_mpi-gcc34-mt-1_35.so.1.35.0 for lack of <pbin.v2/libs/mpi/build/gcc-3.4.6/release/threading-multi>packed_iarchive.o... Any idea on how to solve these? It seems that Boost.MPI is rather 'chummy' with the internals of Boost.Serialization, and that things have changed rather significantly there in 1.36. Regards, Chris Hamilton

2 1

[serialization] ambiguous symbol if include "binary_iarchive.hpp"
by Wang Yun 11 Jun '08

11 Jun '08

Hi, I meet a compile error of boost::function only when I add this line #include <boost/archive/binary_iarchive.hpp> I'm using VC2005, boost 1.35.0 error message: error C2872: 'function' : ambiguous symbol 1> could be 'e:\libraries\boost_1_35_0\boost\function\function_base.hpp(106) : boost::function' 1> or 'boost::detail::function' 1> or 'e:\libraries\boost_1_35_0\boost\function\function_base.hpp(106) : boost::function' // ======= the code =============================== #include "stdafx.h" #include <boost/function.hpp> using boost::function; #include <boost/archive/binary_iarchive.hpp> //////////////// when add this line, error will happen int _tmain(int argc, _TCHAR* argv[]) { function<void()> fn; return 0; } //================================================== Thanks, Wang Yun

3 2