- Boost - lists.preview.boost.org

[test] RFC: speed up BOOST_CHECK by not formatting the check description if it isn't written anywhere
by Ji�� Pale�ek 25 Jul '08

25 Jul '08

Hello, I have a test that uses many BOOST_CHECKs (~ 10 thousands or so). Running that test is very slow and I have noticed most of the time is spent by formatting the description string to be passed to check_impl, only to be ignored, because I don't want to log successful checks (and they are successful). I have improved this by using some kind of expression template for this (called lazy_output). It works like this: lazy_output is a class that implements an expression template for "x << y << z" expressions. The expression o << a << b << c << (make_lazy_output() << x << y << z) is the same as o << a << b << c << x << y << z which is similar to o << a << b << c << (wrap_stringstream().ref() << x << y << z).ref() The difference is that, in the call f(make_lazy_output() << x << y << z), the data is formatted only if f outputs them to an ostream. This reduced the time needed for running my test from ~12 minutes to ~7 minutes. There is more room for similar (but more complicated) improvements. Any comments or suggestions? Regards Jiri Palecek

3 5

Re: [boost] [Boost-testing] Patch for sigaltstack failure on Leopard with XCode 3.0
by Juergen Hunold 25 Jul '08

25 Jul '08

HI Jeroen ! On Sunday 13 July 2008 17:33:04 Jeroen van der Wulp wrote: > Hello everyone, > The cause seems to be that the implementation of sigaltstack() on > Leopard requires the ss_size of a stack_t structure to be MINSIGSTKSZ at > least. > > The attached patch accomplishes just this. Well, it actually sets the size to BOOST_TEST_ALT_STACK_SIZE. But this should be big enough, shouldn't it ? ;-)) I'm CC'ing Gennadyi and the Boost devel list in case he missed this. I'll take a look at the current regressions for trunk and commit this patch tomorrow evening (CEST) if no one is faster ;-)) Merging Boost.Test to release is another business :-(( Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

[Test] [gcc] more checking for Test tests
by Juergen Hunold 25 Jul '08

25 Jul '08

Hi ! I've just fixed some "-pedantic" warnings from gcc. http://svn.boost.org/trac/boost/changeset/47423 I'd like to raise the warning level for gcc when running the Boost.Test testsuite by always adding "-pedantic". Unfortunately, this will issue errors due to gcc's own stdlib (at least for gcc < 4.2) because of the unprotected use of "long long" from the C99 standard. Thanks to Steven Watanabe for pointing this out. I've had to add "-Wno-long-long" to disable those warnings again. Please find a patch including an explanatory comment attached. Comments ? Wait until 1.36 is out ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

generict container for structure of arrays
by Bradford, Chase 24 Jul '08

24 Jul '08

Over the past few months, I've worked on a generalized structure-of-arrays for use in various scientific applications, and wanted to know if any Boostees had an interest in that sort of container. The library's main goals are 1) Optimized storage by allowing dynamic addition/removal of fields. 2) General performance help (cache coherency, vector processing, etc.) 3) Enabling the use of many types in a single SOA. 4) Provide an interface similar other STL containers 5) Type safety (of course) The library is similar to a tuple of vectors, except all vectors are forced to have the same size, and the members of the tuple aren't fixed. Internally, the data is stored as vectors for each field, but there's also an interface for getting a slice of the data. Chase Bradford

6 10

[phoenix] Using Phoenix V2.0
by Robert Jones 24 Jul '08

24 Jul '08

I'm struggling a little to navigate my way through the Boost svn repository for the correct Phoenix V2.0 files. There seem to be many deprecated locations and shell wrappers. Eg. boost/spirit/phoenix/operators.hpp states it is deprected in favour of boost/spirit/include/phoenix1_operators.hpp which simply #includes boost/home/classic/phoenix/operators.hpp which seems to be the real thing. Which, if any, of these is likely to emerge as the 'correct' long term home for these files? Thanks, Rob. -- ACCU - Professionalism in programming - http://www.accu.org

3 5

[graph] Max Flow Uninitialized Warning in adjacency_list.hpp
by Lex Fridman 24 Jul '08

24 Jul '08

When I try to compile the Edmunds Karp Max Flow example (or any of the other max-flow examples) I get a set of warnings as to m_source or m_target being used uninitialized in adjacency_list.hpp. I'm using gcc 4.2.3. Is there a way to get rid of this warning? Code example: http://www.nabble.com/file/p18596627/main.cpp main.cpp Warning example (this is all one line): /usr/include/boost/graph/detail/adjacency_list.hpp: In function ‘int boost::read_dimacs_max_flow(Graph&, CapacityMap, ReverseEdgeMap, typename boost::graph_traits<G>::vertex_descriptor&, typename boost::graph_traits<G>::vertex_descriptor&, std::istream&) [with Graph = main()::Graph, CapacityMap = boost::adj_list_edge_property_map<boost::directed_tag, long int, long int&, unsigned int, boost::property<boost::edge_capacity_t, long int, boost::property<boost::edge_residual_capacity_t, long int, boost::property<boost::edge_reverse_t, boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>, boost::no_property> > >, boost::edge_capacity_t>, ReverseEdgeMap = boost::adj_list_edge_property_map<boost::directed_tag, boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>, boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>&, unsigned int, boost::property<boost::edge_capacity_t, long int, boost::property<boost::edge_residual_capacity_t, long int, boost::property<boost::edge_reverse_t, boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>, boost::no_property> > >, boost::edge_reverse_t>]’: /usr/include/boost/graph/detail/adjacency_list.hpp:270: warning: ‘p.boost::property<boost::edge_capacity_t, long int, boost::property<boost::edge_residual_capacity_t, long int, boost::property<boost::edge_reverse_t, boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>, boost::no_property> > >::<anonymous>.boost::property<boost::edge_residual_capacity_t, long int, boost::property<boost::edge_reverse_t, boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>, boost::no_property> >::<anonymous>.boost::property<boost::edge_reverse_t, boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>, boost::no_property>::m_value.boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>::<anonymous>.boost::detail::edge_base<boost::directed_tag, unsigned int>::m_target’ is used uninitialized in this function -- View this message in context: http://www.nabble.com/-graph--Max-Flow-Uninitialized-Warning-in-adjacency_l… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

[release] nightly generated docs?
by Eric Niebler 24 Jul '08

24 Jul '08

Once upon a time, Boost's docs were built nightly and publicly hosted. Have we fallen out of that practice? Beman, have you tried building the documentation for the release yet? It'd be nice to get a regular build going again so we can work any kinks out of the system. Any volunteers? -- Eric Niebler BoostPro Computing http://www.boostpro.com

5 15

[1.36] release blurb?
by JOAQUIN M. LOPEZ MUÑOZ 24 Jul '08

24 Jul '08

Hi, I wonder whether we already have some place to begin adding content to the 1.36 release notes--you know, listing the new libraries and significant updates. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

6 10

[test] Fixtures and Documentation
by Dean Michael Berris 24 Jul '08

24 Jul '08

Hi Everyone, I've been using Boost.Test for a while already, and although I do think it's a very powerful library, it is a little unweildy to navigate the documentation of the library. For example, currently in the online documentation, links to the examples don't work correctly and there are areas which lead to "404" messages. The question is really simple though: when using BOOST_AUTO_TEST_CASE, how do I cut down on repetitive code and set up "fixtures"? For example, set up variables that are common in all test case bodies in the same file? I'm pretty confident there should be a way to do this -- and if there is, where do I find documentation on it? For now I'll resort to header-reading to find out how to use the macros, though it would be nice to have a one-stop library reference or guide for Boost.Test. TIA -- Dean Michael C. Berris Software Engineer, Friendster, Inc.

3 7

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

Would anybody like a wrapper atomic_shared<T> around shared_ptr<T>?
by Talbot, George 23 Jul '08

23 Jul '08

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. I have a few questions: 1) Is there interest in such a donation. It's just one header file, and it's wafer-thin... 2) If so, how does one go about making such a donation? 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... Thanks in advance for any help/input you can give. -- 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 George T. Talbot, 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 <pthread.h> #include <cerrno> #include <stdexcept> #include <boost/shared_ptr.hpp> #include <boost/pointer_cast.hpp> //#define SPINLOCK_ABORT #ifdef SPINLOCK_ABORT_ON_ERROR #define SPINLOCK_ABORT ::abort(); #else #define SPINLOCK_ABORT #endif /** atomic_shared<T> wraps boost::shared_ptr<T> with a spinlock 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 { /** Initialize a spinlock protecting a shared_ptr<T>. */ static void init(pthread_spinlock_t& l) { int rv = ::pthread_spin_init(&l, PTHREAD_PROCESS_PRIVATE); if (rv) { SPINLOCK_ABORT errno = rv; throw std::runtime_error("can't initialize spinlock"); } } /** Used to lock and unlock a spinlock protecting the shared_ptr<>. * Saves typing. */ struct lock_t { explicit lock_t(pthread_spinlock_t& lock) : m_lock(lock) { if (::pthread_spin_lock(&m_lock)) { SPINLOCK_ABORT throw std::runtime_error("can't lock spinlock"); } } lock_t(pthread_spinlock_t& lock, int) // Assumes already locked. : m_lock(lock) { } ~lock_t() { if (::pthread_spin_unlock(&m_lock)) { SPINLOCK_ABORT } } private: pthread_spinlock_t& m_lock; }; atomic_shared& operator=(const atomic_shared&); public: typedef boost::shared_ptr<T> base_ptr; /** construct an empty pointer. */ atomic_shared() : ptr(), spinlock() { init(spinlock); } /** 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()), spinlock() { init(spinlock); } /** construct a protected pointer from a bare one. */ template<class Y> explicit atomic_shared(Y* p) : ptr(p), spinlock() { init(spinlock); } /** construct a protected pointer from a shared_ptr. */ template<class U> explicit atomic_shared(const boost::shared_ptr<U>& p) : ptr(p), spinlock() { init(spinlock); } /** destructor with rudimentary error checking. */ ~atomic_shared() { int rv = ::pthread_spin_destroy(&spinlock); // For debugging, drop us into the debugger if we can't destroy the // spinlock. assert(rv == 0); (void) rv; } /** Is it not null? */ operator bool() const { bool rv; { lock_t l(spinlock); rv = ptr; } return rv; } /** Is it null? */ bool operator!() const { bool rv; { lock_t l(spinlock); 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; { lock_t l(spinlock); 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 spinlock locked. */ template<class Y, class X> bool compare_and_set(const boost::shared_ptr<Y>& cmp, boost::shared_ptr<X>& x) { bool r; { int rv = ::pthread_spin_trylock(&spinlock); switch (rv) { case EBUSY: return false; case 0: break; default: SPINLOCK_ABORT errno = rv; throw std::logic_error("can't pthread_spin_trylock"); } lock_t l(spinlock, 0); // already locked r = ptr == cmp; if (r) ptr = x; } return r; } private: base_ptr ptr; mutable pthread_spinlock_t spinlock; }; // atomic_shared #endif

3 2

Patch for boost.python: Added return value policy return_pointee_value
by Maximilian Matthe 23 Jul '08

23 Jul '08

Hi! I've created a patch that adds a new return value policy to boost.python: return_pointee_value. Roman Yakovenko has "invented" it, I have added it to the current SVN trunk on my PC. I've written documentation for it and also some test cases. David Abrahams encouraged me to send a patch to the boost list, which I do now. There are some issues with the patch (since its my first time, I'm doing something like that): - The test cases are not integrated into the Jamfile in the tests-directory (I dont know bjam very well). - I dont know, wether the tests are OK the way they are done. - I did not add an #include directive to any boost-python header. But some header should include the <boost/python/return_pointee_value.hpp>, but I dont know which one. Ok, that's it for now. I would aprreciate any comments or critic. Max Index: boost/python/return_pointee_value.hpp =================================================================== --- boost/python/return_pointee_value.hpp (revision 0) +++ boost/python/return_pointee_value.hpp (revision 0) @@ -0,0 +1,69 @@ +// Copyright Roman Yakovenko, Maximilian Matthe 2006, 2008. +// 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) +/* + * Generic return value policy for functions returning pointers which should be + * exposed as values. Can be used to return pointers to non-exposed types. + * + * The code is adapted from + * http://mail.python.org/pipermail/c++-sig/2006-November/011568.html . + */ +#ifndef RETURN_POINTEE_VALUE_9_11_2006 +#define RETURN_POINTEE_VALUE_9_11_2006 + +# include <boost/python/detail/prefix.hpp> +# include <boost/python/detail/indirect_traits.hpp> +# include <boost/python/object.hpp> +# include <boost/mpl/if.hpp> +# include <boost/python/to_python_indirect.hpp> +# include <boost/type_traits/composite_traits.hpp> + + +namespace boost{ namespace python{ + namespace detail{ + struct make_value_holder + { + template <class T> + static PyObject* execute(T* p) + { + if (p == 0) + { + return python::detail::none(); + } + else + { + object p_value( *p ); + return incref( p_value.ptr() ); + } + } + }; + + template <class R> + struct reference_existing_object_requires_a_pointer_return_type +# if defined(__GNUC__) && __GNUC__ >= 3 || defined(__EDG__) + {} +# endif + ; + + } //detail + + struct return_pointee_value + { + template <class T> + struct apply + { + BOOST_STATIC_CONSTANT( bool, ok = is_pointer<T>::value ); + + typedef typename mpl::if_c< + ok + , to_python_indirect<T, detail::make_value_holder> + , detail::reference_existing_object_requires_a_pointer_return_type<T> + >::type type; + }; + }; + + +} } //boost::python + +#endif//RETURN_POINTEE_VALUE_9_11_2006 \ No newline at end of file Index: libs/python/doc/v2/reference.html =================================================================== --- libs/python/doc/v2/reference.html (revision 47690) +++ libs/python/doc/v2/reference.html (working copy) @@ -877,7 +877,25 @@ </dd> </dl> </dd> + + <dt><a href= + "return_pointee_value.html">return_pointee_value.hpp</a></dt> + <dd> + <dl class="index"> + <dt><a href= + "return_pointee_value.html#classes">Classes</a></dt> + + <dd> + <dl class="index"> + <dt><a href= + "return_pointee_value.html#return_pointee_value-spec"> + return_pointee_value</a></dt> + </dl> + </dd> + </dl> + </dd> + <dt><a href="return_by_value.html">return_by_value.hpp</a></dt> <dd> Index: libs/python/doc/v2/reference_existing_object.html =================================================================== --- libs/python/doc/v2/reference_existing_object.html (revision 47690) +++ libs/python/doc/v2/reference_existing_object.html (working copy) @@ -80,6 +80,7 @@ "with_custodian_and_ward.html#with_custodian_and_ward-spec">with_custodian_and_ward</a>. This class is used in the implementation of <a href= "return_internal_reference.html#return_internal_reference-spec">return_internal_reference</a>.</p> + <p>This return value policy can only be used with types that were exposed with boost.python before.</p> <h4><a name="reference_existing_object-spec-synopsis"></a>Class <code>reference_existing_object</code> synopsis</h4> Index: libs/python/doc/v2/return_pointee_value.html =================================================================== --- libs/python/doc/v2/return_pointee_value.html (revision 0) +++ libs/python/doc/v2/return_pointee_value.html (revision 0) @@ -0,0 +1,241 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> + + + + +<html> + <head> + <meta name="generator" content= + "HTML Tidy for Windows (vers 1st August 2002), see www.w3.org"> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <link rel="stylesheet" type="text/css" href="../boost.css"> + + <title>Boost.Python - + <boost/python/return_pointee_value.hpp></title> + </head> + + <body> + <table border="0" cellpadding="7" cellspacing="0" width="100%" summary= + "header"> + <tr> + <td valign="top" width="300"> + <h3><a href="../../../../index.htm"><img height="86" width="277" + alt="C++ Boost" src="../../../../boost.png" border="0"></a></h3> + </td> + + <td valign="top"> + <h1 align="center"><a href="../index.html">Boost.Python</a></h1> + + <h2 align="center">Header + <boost/python/return_pointee_value.hpp></h2> + </td> + </tr> + </table> + <hr> + + <h2>Contents</h2> + + <dl class="page-index"> + <dt><a href="#classes">Classes</a></dt> + + <dd> + <dl class="page-index"> + <dt><a href="#return_pointee_value-spec">Class + <code>return_pointee_value</code></a></dt> + + <dd> + <dl class="page-index"> + <dt><a href="#return_pointee_value-spec-synopsis">Class + <code>return_pointee_value</code> synopsis</a></dt> + + <dt><a href= + "#return_pointee_value-spec-metafunctions">Class + <code>return_pointee_value</code> metafunctions</a></dt> + </dl> + </dd> + </dl> + </dd> + + <dt><a href="#examples">Example</a></dt> + </dl> + <hr> + + <h2><a name="classes"></a>Classes</h2> + + <h3><a name="return_pointee_value-spec"></a>Class + <code>return_pointee_value</code></h3> + + <p><code>return_pointee_value</code> is a model of <a href= + "ResultConverter.html#ResultConverterGenerator-concept">ResultConverterGenerator</a> + which can be used to wrap C++ functions, that return a pointer to a C++ object. The + policy implements the following logic: + + <pre> +if return value is NULL pointer: + return None +else: + return bp::object( * return value ) + </pre> + + It passes the value of the pointee to python, thus the conversion for T is used, if + return value is of type T*.</p> + <p>This return_value_policy can therefore be used to return pointers to python, which + types are not known to boost.python but only a conversion for the pointees. Therefore this + policy should be used to return pointers to objects whose types were wrapped with + other tools, such as SWIG (see example).</p> + + <p><b>Please note:</b> This policy does not take ownership of the wrapped pointer. If the + object pointed to is deleted in C++, the python-object will become invalid too, if your custom + conversion depends on the original object.</p> + + <h4><a name="return_pointee_value-spec-synopsis"></a>Class + <code>return_pointee_value</code> synopsis</h4> +<pre> +namespace boost { namespace python +{ + struct return_pointee_value + { + template <class T> struct apply; + }; +}} +</pre> + + <h4><a name="return_pointee_value-spec-metafunctions"></a>Class + <code>return_pointee_value</code> metafunctions</h4> +<pre> +template <class T> struct apply +</pre> + + <dl class="metafunction-semantics"> + <dt><b>Requires:</b> <code>T</code> is <code>U*</code>for some <code>U</code>.</dt> + + <dt><b>Returns:</b> <code>typedef <a href= + "to_python_indirect.html#to_python_indirect-spec">to_python_indirect</a><T,V> + type</code>, where <code>V</code> is a class whose + static <code>execute</code> function constructs a <code>boost::python::object</code> from + the dereferenced parameter of type <code>U*</code>.</dt> + </dl> + + <h2><a name="examples"></a>Example</h2> + <p><b>Example 1:</b> This example demonstrates the trivial use of <code>return_pointee_value</code> for returning + the value that the returned pointer points to: + </p> + <p>In C++:</p> + <pre> +#include <boost/python/module.hpp> +#include <boost/python/class.hpp> +#include <boost/python/return_pointee_value.hpp> +#include <boost/python/return_value_policy.hpp> +#inlcude <wxPython.h> +#include <utility> + +// The function which is going to be wrapped: +int* get_value() +{ + static int val = 42; + return &val; +} + +// Function that returns a NULL-Pointer +int* get_null_value() +{ + return NULL; +} + +// The wrapper +BOOST_PYTHON_MODULE(example) +{ + using namespace boost::python; + // Wrap the functions with return_pointee_value + def("get_value", get_value, return_value_policy<return_pointee_value>()); + def("get_null_value", get_null_value, return_value_policy<return_pointee_value>()); +} + </pre> + <p>In Python:</p> + <pre> +>>> import example +>>> f = example.get_value() +>>> print f +42 +>>> f = 5 +>>> print example.get_value() +42 +>>> assert None is example.get_null_value() + </pre> + <p>Note that the value of the static C++-variable <code>val</code> is not changed when python assigns + a new value to <code>f</code>. This is caused by the logic of <code>return_pointee_value</code>: It returns + the <code>boost::python::object</code> which is constructed from <code>*val</code>.</p> + + <p><b>Example 2:</b> The following example uses return_pointee_value to return an object that is wrapped + with SWIG. I use the wxPython-API because it's easier to understand.</p> + + <p>In C++:</p> +<pre> +#include <boost/python/module.hpp> +#include <boost/python/class.hpp> +#include <boost/python/return_pointee_value.hpp> +#include <boost/python/return_value_policy.hpp> +#inlcude <wxPython.h> +#include <utility> + +// The following code assumes that there is set up a +// working wxWidgets application + +// Function to wrap: +wxWindow* getMainFrame() +{ + return wxGetApp().GetTopWindow(); +} + +// Custom conversion for wxWindow. +struct convert_wxWindow +{ + // Method that does the conversion. Note that it takes a reference to wxWindow, + // not a reference to a pointer. This is needed, because the return value policy + // converts the objects not the pointers. + static PyObject* convert(wxWindow const& o) + { + // Convert the pointer to wxWindow, instead of its value. This is how + // it should be done to convert wxObjects to wxPython. The object will be + // recognized well in python + PyObject* arg = wxPyMake_wxObject(const_cast<wxWindow*>(&o), false); + return arg; + } +}; + +// Wrapper code +using namespace boost::python; +BOOST_PYTHON_MODULE(MyApp) +{ + def("getMainFrame", getMainFrame, return_value_policy<return_pointee_value>()); + + // register the custom converter + // converter for wxWindow, its conversion_struct, false tells boost that + // we do not have a get_pytype() method in it. + to_python_converter<wxWindow, convert_wxWindow, false>(); +} +</pre> + In Python: The example assumes that you call the python function <code>doit</code> from C++: +<pre> +def doit(): + w = MyApp.getMainFrame() + w.Hide() + print "Haha, it's gone!" + w.Show() + return 0 + +</pre> +<p>Note that the returned wxWindow is the same object as the return value of <code>getMainFrame</code> because of +the custom construction for <code>boost::python::object</code> from wxWindow. The conversion just converts the pointer, +not the object itself.</p> + + <p>Revised +  + 22 July, 2008 +  + </p> + + <p><i>© Copyright Maximilian Matthe, Roman Yakovenko 2006, 2008.</i></p> + </body> +</html> + Index: libs/python/test/return_pointee_value.cpp =================================================================== --- libs/python/test/return_pointee_value.cpp (revision 0) +++ libs/python/test/return_pointee_value.cpp (revision 0) @@ -0,0 +1,55 @@ +// Copyright Maximilian Matthe 2008. +// 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) + +#include <boost/python/return_pointee_value.hpp> +#include <boost/python/module.hpp> +#include <boost/python/return_value_policy.hpp> +#include <boost/python/def.hpp> +#include <boost/python/to_python_converter.hpp> + +// Out returned, unkown type +struct IntWrapper +{ + IntWrapper(int v) : val(v) {} + int val; +}; + +// the custom converter +struct convert_IntWrapper +{ + static PyObject* convert(IntWrapper const& w) + { + return boost::python::incref(boost::python::object(w.val).ptr()); + } +}; + +IntWrapper* returnIntWrapper() +{ + static IntWrapper w(42); + return &w; +} + +////////////////////////////////////////////////////////// +float* get_value() +{ + static float value = 0.5f; + return &value; +} + +float* get_null_value() +{ + return NULL; +} + +BOOST_PYTHON_MODULE(return_pointee_value) +{ + using namespace boost::python; + def("returnIntWrapper", returnIntWrapper, return_value_policy<return_pointee_value>()); + + def("get_value", get_value, return_value_policy<return_pointee_value>()); + def("get_null_value", get_null_value, return_value_policy<return_pointee_value>()); + + to_python_converter<IntWrapper, convert_IntWrapper, false>(); +} \ No newline at end of file Index: libs/python/test/return_pointee_value.py =================================================================== --- libs/python/test/return_pointee_value.py (revision 0) +++ libs/python/test/return_pointee_value.py (revision 0) @@ -0,0 +1,25 @@ +# Copyright Maximilian Matthe 2008 +# 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) + +import return_pointee_value + + +def run(args = None): + a = return_pointee_value.returnIntWrapper() + assert a == 42 + assert 0.5 == return_pointee_value.get_value() + assert None is return_pointee_value.get_null_value() + return 0 + +if __name__ == '__main__': + print 'running...' + import sys + status = run() + if(status == 0): + print "Succes..." + else: + print "Failure!" + sys.exit(status) + \ No newline at end of file

2 1

[dataflow] new frameworks and GUI editors + visually edit a BGL graph
by Stjepan Rajko 22 Jul '08

22 Jul '08

Hello, I uploaded some youtube videos of a new visual editor for the Dataflow library. There are three examples, each using a different underlying framework (the visual editor code is generic): visually editing a Dataflow.Signals network (data flows instantly): * http://www.youtube.com/watch?v=7a4HJ4zVPXc visually editing a Dataflow.Managed network (data flows on request): * http://www.youtube.com/watch?v=KwrnSjhJyf4 visually editing a BGL graph (this simple example lets you construct a directed graph and query the number of strongly connected components): * http://www.youtube.com/watch?v=gVLetAAnPrc The latter two examples use proof-of-concept implementations of alternate frameworks built on top of the generic framework that is part of the Dataflow library: Dataflow.Managed is unlike Dataflow.Signals in that doesn't couple data transfer with component invocation. In other words, if producer A is connected to consumer B, when A changes its value B will not be notified immediately. Instead, after any number of values in the network has changed, the network as a whole can be told to update (the network will then notify all components whose inputs have been modified, in the order of a topological sort of the components). Alternatively, components can be invoked individually, which gives them a chance to check their inputs / modify their outputs. The BGL support layer for the Dataflow library is an example of how something that is not strictly a dataflow thing (e.g., a graph) can still satisfy Dataflow concepts (there are Components (vertices) that can be connected), and be used with the framework (e.g., you get a GUI editor for free). If you're interested in playing with this: The new GUI uses GLV (http://mat.ucsb.edu/glv/) which is included with the dataflow library in the sandbox and integrated in the bjam build of the examples. As long as you have glut/freeglut available, it should build using gcc/darwin, MSVC8+, gcc/minGW, and if you are better than me at knowing which X libraries to link with and know how to manipulate a Jamfile, gcc/linux (any GCC version 4.x should work). If you run into any problems, please let me know. The latest code is currently available from the sandbox only, instructions/docs at: http://www.dancinghacker.com/code/dataflow/ Any feedback would be appreciated. Kind regards, Stjepan

3 10

[phoenix] What is its state of play?
by Robert Jones 22 Jul '08

22 Jul '08

Hi I've just started looking at the Boost.Phoenix library, from a cold start, and I'm a bit confused! What version is current atm? It seems to be in flux between v1.2.1 and v2.0. Also, if someone could say a few words about any relationship between Phoenix and Lambda I'd really appreciate it. Does Phoenix replace Lambda, complement or coexist with it? Many Thanks, Rob.

2 1

[boostbook] Windows xsltlproc binary packages
by Daniel James 22 Jul '08

22 Jul '08

Hi, Is the version of xsltproc on the meta-comm site still not working? If it is, and it isn't possible to replace it, I'll change the boostbook documentation to link to the same binaries as the quickbook documentation (patch attached). thanks, Daniel

2 1

[phoenix] Where is the documentation?
by Robert Jones 22 Jul '08

22 Jul '08

Is there any definitive documentation for Phoenix? I've found http://www.boost.org/doc/libs/1_35_0/libs/spirit/phoenix/index.html http://spirit.sourceforge.net/dl_docs/phoenix-2/libs/spirit/phoenix/doc/htm… and various other web references, but I'm unsure if either is authoritative. Also, are any books about it? Alone the lines of Karlsson's book for Lambda? Thanks, Rob.

1 0