July 2008 - Boost - lists.boost.org

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

Re: [boost] [integer] Recent changes introduced failures on many platforms
by joaquin＠tid.es 22 Jul '08

22 Jul '08

Daryle Walker escribió: > Some of the compilers had weird errors reading in the preprocessor > marker '#' as regular code. I suspect that some compilers don't like > preprocessor selection within a macro-function call, which is what > I'm doing. I'll fix that first and we'll see what happens. > I think that this is in fact illegal according to Cpp rules. Mr. Mensonides or Mr. Kaiser will undoubtedly be able to tell for sure. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[lambda] Binding to templated functions
by Robert Jones 22 Jul '08

22 Jul '08

The Boost.Lambda library continues to delight and frustrate me! I have this code sequence, which is intended to determine whether a predicate is true for all objects pointed to by the second member of all of vector of pairs, #include <utility> #include <vector> #include <algorithm> #include "boost/lambda/lambda.hpp" #include "boost/lambda/bind.hpp" struct S { bool predOfS( ); }; int main( ) { using namespace std; using namespace boost :: lambda; typedef pair<int, S *> Pair; vector<Pair> pairs; bool trueForAll = ( find_if( _1, _2, _3 ) == _2 )( pairs.begin( ), pairs.end( ), ! bind( & S :: predOfS, bind( & Pair :: second, _1 ) ) ); } The last line gives me compile errors. Two things: - I think I need to specicy the template parameters to find_if, but I'm not sure quite what they are! - The error message reckons the last arg to find_if is placeholder<4>, not placeholder<3>, why? Or maybe there's completely different way to do this kind of thing? Thanks, Rob.

2 2

[integer] Proposal: minor addition to cstdint.hpp: largest integer types for value-based template arguments
by Daryle Walker 22 Jul '08

22 Jul '08

I just added some class templates that had declarations like: //======================================== template < intmax_t Value > struct whatever; //======================================== Afterwards, I was looking over some of the Boost.Integer headers and got curious about the BOOST_NO_INTEGRAL_INT64_T setting used within <boost/integer_traits.hpp>. I think we could add two typedefs to <boost/cstdint.hpp> //======================================== #if !defined(BOOST_NO_INT64_T) && defined(BOOST_NO_INTEGRAL_INT64_T) typedef signed long intmaxc_t; typedef unsigned long uintmaxc_t; #else typedef intmax_t intmaxc_t; typedef uintmax_t uintmaxc_t; #endif //======================================== Where "intmaxc_t" is the largest signed integer type that is suitable for integer constant expressions (like value-based template parameters) and "uintmaxc_t" is the unsigned equivalent. They should be the same as "intmax_t" and "uintmax_t" on non-broken compilers. I'd change my code to use the new types, to be safer. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 1