- Boost - lists.boost.org

Re: [boost] [1.36.0] Libraries with unmerged changes?
by Alp Mestan 24 Jul '08

24 Jul '08

Just must write a non-explicit constructor for io::chain taking an io::read_mem. Any reason for it to be dangerous ? -- Alp Mestan --- http://blog.mestan.fr/ --- http://alp.developpez.com/ --- In charge of the Qt, Algorithms and Artificial Intelligence sections on Developpez

1 0

[test] documentatation on patmedia.net disappeared, not up to date on boost.org
by Leo Moisio 23 Jul '08

23 Jul '08

The documentation for Boost.Test on boost.org seems very outdated, but there has been a much more up to date documentation available on http://www.patmedia.net/~rogeeff/html/utf/user-guide.html However it disappeared yesterday or day before that, and I can't find any mirrors anywhere. I'd really like to have this documentation available again. Leo Moisio

9 16

Boost Developers and the Sandbox
by Robert Jones 23 Jul '08

23 Jul '08

Am I correct in thinking that the Boost sandbox in entirely contained on the sourceforge site in the Boost Sandbox project, and that it's not part of, or contained in, the main Boost site? Also, I see the Boost Project has only 130 developers, and the Boost Sandbox Project only 89. This is the entire Boost development community? Or do these people commonly commit on behalf of others? Thanks, Rob. -- ACCU - Professionalism in programming - http://www.accu.org

2 2

OS X Test error
by Jeremy Pack 23 Jul '08

23 Jul '08

I am getting the following error when building any Boost tests on OS X 10.5: ====== BEGIN OUTPUT ====== Test setup error: system_error produced by: ::sigaltstack( &sigstk, 0 ) != -1: Cannot allocate memory EXIT STATUS: 200 ====== END OUTPUT ====== Anyone seen this before? Jeremy Pack

4 8

[shifted_ptr] STL w/ smart pointers
by Phil Bouchard 23 Jul '08

23 Jul '08

Hi, If we look into sandbox/shifted_ptr/bits I've added an archive called "bits.zip". I archived it because of all the barking SVN was doing. By unpacking this file we'll find: stl_list.h list.tcc stl_list.h.patch list.tcc.patch These files are an overriden version of the Gnu Gcc's 3.4.x headers. Why Gcc's? Because SGI headers are outdated by many years. Now if we compile shifted_ptr_test2.cpp with the following then these headers will override system ones which is perfect: g++ shifted_ptr_test2.cpp -I ../../.. My example doesn't work anymore but compiles at least. I will work on the problem but for now we can see the required changes to make STL compliant with smart pointers in the patch files. I think this is great because this can help unobfusticate the standards in this matter and containers using smart pointers means better abstraction and goodbye to a lot of headaches if we start using sorting, multi-indexing, graph, etc. In the code itself I am propagating the allocator all over internal classes (iterators & nodes) and now looks like the following: template<typename _Alloc> struct _List_node_base { typedef typename _Alloc::template rebind<_List_node_base<_Alloc> >::other _Node_Alloc_type; typedef typename _Node_Alloc_type::pointer pointer; typedef typename _Node_Alloc_type::const_pointer const_pointer; typedef typename _Node_Alloc_type::reference reference; typedef typename _Node_Alloc_type::const_reference const_reference; pointer _M_next; ///< Self-explanatory pointer _M_prev; ///< Self-explanatory static void swap(_List_node_base& __x, _List_node_base& __y); void transfer(pointer const __first, pointer const __last); void reverse(); void hook(pointer const & __position); void unhook(); }; Furtermore I took the liberty of mixing the Boost License with GPL because I think these are compatible but feel free letting me know any problem this may create. Regards, -Phil

2 3

Inspection reports updated
by Marshall Clow 23 Jul '08

23 Jul '08

I have updated the inspection reports at: <http://www.idio.com/misc/inspect-release.html> <http://www.idio.com/misc/inspect-trunk.html> Summaries: Release: >20776 files scanned >1625 directories scanned (including root) >838 problems reported > >Problem counts: > 260 files missing Boost license info or having wrong reference text > 188 files missing copyright notice > 1 files with invalid line endings > 0 bookmarks with invalid characters > 2 invalid urls > 113 broken links > 34 unlinked files > 7 file/directory names issues > 44 files with tabs > 116 files with non-ASCII chars > 33 violations of the Boost min/max guidelines > 40 usages of unnamed namespaces in headers (including .ipp files) Trunk: >21573 files scanned >1671 directories scanned (including root) >1532 problems reported > >Problem counts: > 548 files missing Boost license info or having wrong reference text > 294 files missing copyright notice > 1 files with invalid line endings > 0 bookmarks with invalid characters > 2 invalid urls > 119 broken links > 47 unlinked files > 26 file/directory names issues > 320 files with tabs > 71 files with non-ASCII chars > 64 violations of the Boost min/max guidelines > 40 usages of unnamed namespaces in headers (including .ipp files) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

4 8

Re: [boost] Would anybody like a wrapper atomic_shared<T>aroundshared_ptr<T>?
by Talbot, George 23 Jul '08

23 Jul '08

Excellent. I'll wait for this. I'd be willing to be a tester, if that would help. -- George T. Talbot <gtalbot(a)locuspharma.com> > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Peter Dimov > Sent: Wednesday, July 23, 2008 6:37 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Would anybody like a wrapper > atomic_shared<T>aroundshared_ptr<T>? > > Talbot, George: > > > Hi all, > > > > A while back (~2006 I think) I was asking around on this list about > > using boost::shared_ptr<T> to build a composite data structure that can > > be accessed and modified by multiple threads. > > > > Peter Dimov's suggestion at the time was to write a wrapper class for > > boost::shared_ptr<T> that would protect access to the > > boost::shared_ptr<T> with a spinlock. I've done this, and this works > > pretty good in my application. I'm interested in contributing this code > > to BOOST, as it's been quite useful. > > The SVN now contains an implementation of the recently accepted for > inclusion into C++0x > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2674.htm > > This feature be part of the upcoming 1.36. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Would anybody like a wrapper atomic_shared<T> aroundshared_ptr<T>?
by Talbot, George 23 Jul '08

23 Jul '08

Hi! Thanks for responding. > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Dean Michael Berris > Sent: Tuesday, July 22, 2008 9:24 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Would anybody like a wrapper atomic_shared<T> > aroundshared_ptr<T>? > > Hi George, > > On Wed, Jul 23, 2008 at 6:04 AM, Talbot, George <Gtalbot(a)locuspharma.com> > wrote: > > > > A while back (~2006 I think) I was asking around on this list about > > using boost::shared_ptr<T> to build a composite data structure that can > > be accessed and modified by multiple threads. > > > > Peter Dimov's suggestion at the time was to write a wrapper class for > > boost::shared_ptr<T> that would protect access to the > > boost::shared_ptr<T> with a spinlock. I've done this, and this works > > pretty good in my application. I'm interested in contributing this code > > to BOOST, as it's been quite useful. > > > > I have a few questions: > > > > 1) Is there interest in such a donation. It's just one header file, > > and it's wafer-thin... > > I am interested, although I do have some reservations with it not > using the locks already available in Boost.Thread. I would likely convert it to do so. Haven't got around to that yet. > > 2) If so, how does one go about making such a donation? > > (I think it's a little funny that you use 'donation' instead of > contribution... but nonetheless... ;-) ) Sorry....contribution. I'm a bit of a space cadet. ;^) > >From what I gather, this is something that may have to go through a > mini-review. The veterans can answer this question better though. I'm sure, and that would be great, actually. > > 3) My implementation below uses a spinlock to protect things and > > as one might expect, under load my application does spend some > > time in ::pthread_spin_lock(). Is there a way to rewrite this > > class (possibly with friendship of boost::shared_ptr<T>) in a > > lock-free manner? I've attached the code below... > > > > I'm not sure about lock-free approaches, but doesn't shared_ptr<T> > already use atomic operations when built in multi-threaded mode? Yes, but read the Thread Safety page. The guarantee you get from shared_ptr<T> is that two or more separate instances in separate threads that point to the same object and refcount will be handled lock-free and work properly. However it explicitly does not guarantee multiple threads looking at the _same_ instance of shared_ptr<T> can perform operations upon that same instance without some sort of additional guarantees. The purpose of this class is to provide that guarantee. > Another issue I see is the dependence to ::pthread_spin_lock() -- can > you use a shared recursive_mutex instead? How expensive is that in memory and time? I was using ::pthread_spin_lock() because on my x86_64 Linux box, pthread_spinlock_t is a single machine word. Also, it's just a proof-of-concept. I think the "right thing" is to be able to implement the unary bool operators, get() and compare_and_set() via a lock-free algorithm. My problem is that I don't have enough depth of knowledge of the lock-free shared_ptr<T> class in BOOST to be able to work out such an algorithm. I was hoping for a little bit of "pointing in the right direction" from the author(s) of BOOST's lock-free shared_ptr<T> implementation. That said I'd have no problem "falling-back" to using a shared recursive_mutex instead if a lock-free algorithm isn't available on a particular platform. As such, attached below is a rewrite using recursive_try_mutex...This appears similar in execution efficiency to my previous implementation with the spinlock in my stress test. It appears from examining the pthread libraries that the mutex is using about 8 machine words instead of one for the spinlock. Of course, as above, I'd prefer no lock at all; I'll see what I can come up with. Thanks for looking at this. -- George T. Talbot gtalbot(a)locuspharma.com /** \file atomic_shared.h * * \author George T. Talbot * \author Peter Dimov * * \brief This file defines a template class that can wrap * boost::shared_ptr and provide thread-safe atomic * get/set operations on them. * * (C) Copyright Locus Pharmaceuticals, Inc., Peter Dimov 2006. * * Distributed under 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) */ #ifndef ATOMIC_SHARED_H #define ATOMIC_SHARED_H #include <boost/shared_ptr.hpp> #include <boost/pointer_cast.hpp> #include <boost/thread/recursive_mutex.hpp> /** atomic_shared<T> wraps boost::shared_ptr<T> with a mutex and a very * restricted set of operations so that a large composite data structure * may be accessed by multiple threads with a minimum of locking contention. * * Threads working on a large composite data structure create their own * private boost::shared_ptr<T> around their own new nodes and then use * compare_and_set() to place their new nodes in the composite data * structure. * * Threads that are viewing the composite data structure may call get() to * get a private copy of the pointer so they can do some work with it. The * intended idiom for modifications to nodes is like so: * * \code * * atomic_shared<const Blah> global_blah; * * void modify_the_global_blah_in_many_threads_with_no_locking() * { * bool done = false; * do * { * boost::shared_ptr<const Blah> my_blah(global_blah.get()); * * boost::shared_ptr<Blah> new_blah(*my_blah); * new_blah->some_modification(); * done = global_blah.compare_and_set(my_blah, new_blah); * } * while (!done); * } * * \endcode * * Threads that just need to do some work looking at the node: * * \code * * void print_the_global_blah_in_many_threads_with_no_locking() * { * boost::shared_ptr<const Blah> my_blah(global_blah.get()); * * my_blah->print(); * } * * \endcode * * Using atomic_shared<T> this way satisfies the Thread Safety portion of * the boost::shared_ptr<T> documentation. */ template<class T> class atomic_shared { atomic_shared& operator=(const atomic_shared&); public: typedef boost::shared_ptr<T> base_ptr; /** construct an empty pointer. */ atomic_shared() : ptr(), mutex() { } /** copy constructor. Since we like to put atomic_shared<> in std::map<> * via std::map<atomic_shared<T> >::insert(std::make_pair(key, value)), * this needs to be here. */ atomic_shared(const atomic_shared& p) : ptr(p.get()), mutex() { } /** construct a protected pointer from a bare one. */ template<class Y> explicit atomic_shared(Y* p) : ptr(p), mutex() { } /** construct a protected pointer from a shared_ptr. */ template<class U> explicit atomic_shared(const boost::shared_ptr<U>& p) : ptr(p), mutex() { } ~atomic_shared() { } /** Is it not null? */ operator bool() const { bool rv; { boost::recursive_try_mutex::scoped_lock l(mutex); rv = ptr; } return rv; } /** Is it null? */ bool operator!() const { bool rv; { boost::recursive_try_mutex::scoped_lock l(mutex); rv = !ptr; } return rv; } /** Right here is the only way to _use_ the pointer. To use what the * pointer is pointing to, you must make a private copy in your * thread. */ inline base_ptr get() const { base_ptr p; { boost::recursive_try_mutex::scoped_lock l(mutex); p = ptr; } return p; } /** Attempt to set the value of the pointer with another pointer, but * only if the pointer is the same as a previously sampled value of * the pointer. * * @param cmp Value of pointer previously retrieved with get(). * @param x New value of pointer. * @return true if the pointer could be set to x (i.e. its value was * still cmp with the mutex locked.) */ template<class Y, class X> bool compare_and_set(const boost::shared_ptr<Y>& cmp, boost::shared_ptr<X>& x) { bool r = false; boost::recursive_try_mutex::scoped_try_lock l(mutex, false); if (l.try_lock()) { r = ptr == cmp; if (r) ptr = x; } return r; } private: base_ptr ptr; mutable boost::recursive_try_mutex mutex; }; // atomic_shared #endif

1 0

[web-site] Documentation links.
by Jurko Gospodnetić 23 Jul '08

23 Jul '08

Hi. A few issues related to the documentation link organization on the new web site: ---- 1. ---- The libraries documentation link list on the http://beta.boost.org/doc/ page (the main link list as well as the one in the menu on the right hand side) should be updated to reference the 1.36.0 release web page as the current release. ---- 2. ---- Could the tool documentation links on http://beta.boost.org/doc/ be better organized somehow? Currently it is not clear that the 'Tools' bullet is a link to a page with all the tool documentation links and user thinks that Boost Jam & Boost Build are the only two documented (or existing) tools. Some ideas: (1) Remove Boost Jam & Boost Build links and leave just the 'Tools' link. (2) Add an 'All tools...' link below the Boost Build link. (3) Integrate the whole http://beta.boost.org/doc/tools.html web page into its parent page at http://beta.boost.org/doc/. My choice would be (3). ---- 3. ---- There is a similar problem with the links on the right side of the http://beta.boost.org/doc/ page where similar ideas apply and my suggestion would be to list all the tools below the Tools parent menu item. I've seen this same suggestion made before in some thread, and recalled it now after actually having to look for some tool documentation and experiencing the problem for myself. Hope this helps. Best regards, Jurko Gospodnetić

2 1

Re: [boost] [pool] segfault (fun with static initialization ordering)
by JOAQUIN M. LOPEZ MUÑOZ 23 Jul '08

23 Jul '08

_______________________________________ De: boost-bounces(a)lists.boost.org [boost-bounces(a)lists.boost.org] En nombre de Chris Newbold [Chris.Newbold(a)mathworks.com] Enviado el: viernes, 11 de julio de 2008 16:25 Para: 'boost(a)lists.boost.org' Asunto: Re: [boost] [pool] segfault (fun with static initialization ordering) [...] > Right. The way that singleton_default guarantees that instance() is called during > dynamic initialization is by [analysis of singleton machinery] That's it. > > * Where the problem lies can be found by looking at the usage of > > singleton_pool by fast_pool_allocator: notice that singleton_pool > > is used *only* when fast_pool_allocator::allocate or ::deallocate > > are invoked. So, it is perfectly possible to construct a > > fast_pool_allocator without that forcing the compiler to > > construct the underying singleton_pool *yet*. And this is what's > > happening indeed, the sequence of objects construction we're > > having is this: > > > > 1. owned_base::pool_ begins construction > > 1.1 call of new pool_lii() inside pool::pool > > 1.1.1 a fast_pool_allocator is cted inside pool_lii ctor. > > 1.2 pool_ii ends construction > > 2. pool_ ends construction > > 3. the singleton instance associated to singleton_pool<...>is > > cted before main() because fast_pool_allocator uses it later > > (singleton guarantee). > > I'm not sure I buy this explanation entirely. > > owned_base::pool_ is a global object. As described above, so is object_creator. > The test case consists of a single translation unit, and inside that translation > unit, the declaration of object_creator precedes that of owned_base::pool_ > (because object_creator is declared by a Boost.Pool header which is included > before the application-level code which declares owned_base). > > Following the fairly clear rules about initialization order for namespace-scoped > global objects, I would have expected the compiler to construct object_creator > first (and therefore the pool) before constructing owned_base::pool_. These precedence rules do not apply to class template static data: quoting the standard (latest draft at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf) section 3.6.2: "Dynamic initialization of a non-local object with static storage duration is either ordered or unordered. Definitions of explicitly specialized class template static data members have ordered initialization. Other class template static data members (i.e., implicitly or explicitly instantiated specializations) have unordered initialization. Other objects defined in namespace scope have ordered initialization. Objects with ordered initialization defined within a single translation unit shall be initialized in theorder of their definitions in the translation unit." That is, only *ordered* file-scope objects are subject to the precedence rule you're referring to. Class template static data are not ordered by definition (except if belonging to a full specialization). So, the sequence I proposed above is consistent AFAICS. The following is a case where the precende rule *cannot* be applied for logical reasons: template<typename T> struct foo{ static int x; }; template<typename T> int foo<T>::x=T::x; struct bar { static int x; }; int bar::x=666; static int x=foo<bar>::x; You see, foo<T>::x is defined before bar::x yet it can only be initialized after bar::x has already been constructed. In the original case we're dealing with there are no dependency constraints like this, yet the sequence I proposed a post ago is to the best of my knowledge consistent with the rules of C++ (and we're seemingly observing it in at least a compiler). BTW, have you tried the fix I was proposing? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3