- Boost - lists.preview.boost.org

[smart_ptr] release()
by Phil Bouchard 09 Sep '08

09 Sep '08

As it turns out I think a release() member function should be added to the smart pointer. Its purpose is to give away ownership of the object. See the following pseudo-code: template <typename T> class smart_ptr { ... smart_ptr(element_type *); value_type * get(); element_type * release() { element_type * __p = pointer_ref(); pointer_ref() = 0; if (-- counter_ref()) return 0; else return __p; } }; It follows the same idea of its predecessor auto_ptr<> but will return a null pointer if the object is still shared thus not ready to be deleted. This way the allocator will be much easier to support either by calling this function before deallocate(), inside it or by using a specialized wrapper class to handle it: template <typename T> class allocator { ... typedef smart_ptr<T> pointer; void deallocate(pointer & __p) { delete p.release(); } }; -Phil

6 15

[thread_safe_signals] changing the namespace used
by Stjepan Rajko 09 Sep '08

09 Sep '08

Hello, In trying to use thread_safe_signals with Dataflow.Signals, I did the following before including the headers to cause thread_safe_signals to use the boost::signals namespace instead of boost::signalslib (I needed this because Dataflow.Signals adds to the boost::signals namespace): #define signalslib signals #define signals signals The first line was to change the namespace used, and the second to prevent thread_safe_signals from aliasing boost::signals to itself. This worked for gcc on OS X, but I just found out that msvc 2005 express chokes on it (in some preprocessing file iteration loop). Is there a better solution for this? Thanks, Stjepan

2 2

[dataflow][review] loading Dataflow.Signals components from shared libraries
by Stjepan Rajko 09 Sep '08

09 Sep '08

In the Dataflow library / Dataflow.Signals layer review discussions, a few people have mentioned the potential usefulness of loading components at runtime (e.g., from a shared library). I put together a small example of how this could be done for Dataflow.Signals components using the (prototype) Dataflow.Blueprint layer and the Extension library: http://svn.boost.org/svn/boost/sandbox/SOC/2007/signals/libs/dataflow/examp… The component_add.cpp file contains the implementation of a component (that adds two numbers and outputs the result), and the code required to access it through an Extension factory_map. The extension_example.cpp file loads the shared library created from component_add.cpp, instantiates the provided component, and uses it to complete a network. The Blueprint layer is still under development (and has somewhat ugly syntax), but I hope this example can still demonstrate some future possibilities of the Dataflow library with regards to loading components at run-time. It has been tested to work with MSVC 2005. Regards, Stjepan

1 0

[asio] Support for raw sockets and ICMP in latest version
by Carlo Medas 08 Sep '08

08 Sep '08

Dear Asio developers, I've seen with some excitement the new release which announces raw sockets and ICMP support. Since I've not been able to find any new example showing usage of these features, I've tried to investigate the code but I still got the same question: is ICMP packet receive/sending supported? And moreover, are raw data (IP layer?) sockets supported and thus usable? Thanks in advance. Kind regards, Carlo Medas

1 0

Re: [boost] [boost numeric binding] patch
by Michael Gauckler 08 Sep '08

08 Sep '08

Hi Thomas, Under Linux gccxml is setting the __GNUC__ and everything works. Under Windows it is trying to emulate msvc (and therefore not setting __GNUC__), this is why it fails and why this additional check is necessary. Attached again the patch, which also indicates which files needs to be patched. Regards, Michael

1 0

Re: [boost] [boost numeric binding] patch
by Thomas Klimpel 08 Sep '08

08 Sep '08

Hello Michael, I could certainly apply your patch, but why doesn't GCCXML defines __GNUC__ in the first place, when it's effectively just a gcc? Or is it indeed different from gcc, so that I should test that it really works? Regards, Thomas

1 0

[RFC] Boost library name mangling and Microsoft's 'secure STL' feature.
by Jurko Gospodnetić 08 Sep '08

08 Sep '08

Hi all. There have been requests to make Boost Build cleanly support Microsoft's 'secure STL'/'checked iterators' feature. Here's is one suggested implementation and how that will affect building Boost libraries on Windows: We add a new <msvc-checked-iterators> Boost Build feature with values 'off' and 'on' and 'off' being the default. The effect of the feature would be to define the SCL_SECURE preprocessor constant to 1 for feature value 'on' or to 0 for feature value off. This would affect only code compiled using MSVC compiler versions 8.0 & above. Libraries compiled with compilers affected by this setting would have their name mangling changed as follows: * If the setting is 'off' there would be no change. * If the setting is 'on' the name would get en extra letter 'c' added to its 'runtime tag' letter group (together with 's' for statically linked libraries, 'd' for debug, 'p' for the stlport standard library, etc.). Effects this would have on Boost libraries: * If we implement the proposed solution the default Boost library build behaviour will change. Boost libraries built by default will have Microsoft's secure STL (a.k.a. checking iterator) support disabled while currently, when we do nothing explicit about those settings, Microsoft compilers enable that support by default. * Making a complete Boost library build using the MSVC toolset will take twice as long as there may now be twice as many property combinations affecting the build. On the other hand user can always easily choose from the build command line which versions he wants in case he wants a subset. Selecting msvc-checked-iterators=on would get the current default behaviour. Some extra ideas to consider: * Add an additional 'default' feature value which would cause Boost Build to do nothing. This would on the other hand mess up library name mangling unless Boost Build were taught to know exactly what defaults each compiler or compiler version uses. Please give your comments on at least the following: * Feature name. * Any additional values that might be needed. * Any additional compiler flags/options/preprocessor constants that might be related to this. * Default value. * Library name mangling. * Any additional compilers this might affect, e.g. Comeau, Intel, etc. * Any additional runtime libraries this might affect, e.g. stlport. Many thanks for any feedback you can provide. Best regards, Jurko Gospodnetić

12 22

Mixed use of "include" directives with quoted vs. angle-bracketed params, causing havoc
by Victor Vojtech Terber 08 Sep '08

08 Sep '08

I have multiple Boost versions installed in different file locations. I occasionally ran into problems with mixed-up Boost headers. This was due to Boost's use of both quoted and bracketed syntax of the include directive to include its headers. The standard allows for different results for resolving the include directive depending on the chosen form. In particular the angle-bracketed form is narrower than the quoted one (see chapters 16.2.2 and 3). So the point in the file system from where the file will actually be included may legally differ, based on the form of the include directive. I don't mind which alternative Boost uses. But in my opinion it should be consistent inside Boost headers, shouldn't it? With some file system layouts it gets very inconvenient to pre-determine by simple set-up of compiler or environment variables which version will get used. I also fail to see any obvious downside of a unification.

8 15

[dataflow][review] Dataflow.Signals and threading - new docs and examples
by Stjepan Rajko 07 Sep '08

07 Sep '08

Hello, I have added a section on threading to the Dataflow.Signals tutorial: http://tinyurl.com/69subd (my hosting provider appears to be having some intermittent problems today - I apologize to any reviewers impacted by this) This new section summarizes information related to threading, and presents a new example component that uses the Threadpool library by Oliver Kowalke to provide support for asynchronous signals. Here is an excerpt regarding the Threadpool component: The purpose of the component is to make a signal call asynchronous. Instead of the consumer component processing the signal immediately, the signal call will be added to a thread pool and processed later. async_component is a class template, templated on the threadpool type, and the type of the underlying component that will process the asynchronous signal. The three examples provided are: * mixing synchronous and asynchronous signals * assigning priorities to tasks / signals * using asynchronous signals for cyclic networks Thanks to everyone that has participated in the discussion regarding this library so far. I hope this documentation update will provide some additional information on how the library can be used / extended. Stjepan

1 0

[boost numeric binding] patch
by Michael Gauckler 07 Sep '08

07 Sep '08

Hi, I have a little patch (a three-liner, given below) that allows the boost numeric bindings to be parsed by GCCXML. Can somebody with write-access to the sandbox please apply this little patch? Thanks. Best regards, Michael 21a22,23 > #elif defined(__GCCXML__) >

1 0

What's up with the trunk test summary?
by Emil Dotchevski 07 Sep '08

07 Sep '08

This link doesn't quite work for me: http://beta.boost.org/development/tests/trunk/developer/summary.html Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

3 2

[threadpool] determining whether a Threadpool type uses a priority/attribute
by Stjepan Rajko 07 Sep '08

07 Sep '08

Hello, Suppose I have a Threadpool type, which could for example be either of the following: tp::pool< tp::fixed, tp::unbounded_channel< tp::priority< int > > > -or- tp::pool< tp::fixed, tp::unbounded_channel< tp::fifo > > How do I find out whether Threadpool involves a priority/attribute, and what the type of it is? For example, I am looking for something that would give me: // returns something like mpl::true_ for the first case // returns something like mpl::false_ for the second case has_priority<Threadpool>::type // returns int for the first case priority_type<Threadpool>::type Thanks in advance, Stjepan

3 4

lifetime of ranges vs. iterators
by Arno Schödl 07 Sep '08

07 Sep '08

Hello, some adaptor ranges need certain constant information about their underlying ranges. For example, iterating over a forward "difference_range", the difference between two sorted ranges, requires access to the ends of the underlying ranges. These two additional iterators are constant, they do not change when the difference_iterator is incremented. Now, where should this additional constant information be stored? a) In the difference_range, and each iterator holds a reference to the difference_range? That requires the difference_range to be alive as long as its iterators are alive. This may be difficult to ensure if the difference_range is a temporary. b) In the iterators, so the lifetime of adaptor iterators is independent of the adaptor range. Of course, one can use shared_ptrs and so on, but still the iterators are ultimately responsible to keep that information available. This initially seemed more natural to me, but if implemented naively by storing the additional iterators in the iterator itself, it leads to storage bloat: each difference_iterator needs 4 instead of 2 of its underlying iterators. When stacking difference iterators, the difference in required storage grows exponentially: instead of 2^N, you need 4^N storage... I feel that in order to solidify the range concept, one needs to make a choice whether a) or b) is "standard", because any user of ranges would need to know. Any thoughts on this? Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229

7 118

Re: [boost] Mentoring students
by Chris De Vries 07 Sep '08

07 Sep '08

> on Thu Sep 04 2008, "Chris De Vries" <cdevries-AT-ieee.org> wrote: >> Hi, >> >> My name is Chris De Vries and I am involved with the IEEE student branch at >> the Queensland University of Technology in Brisbane, Australia [1]. I am >> organizing a program that encourages students to become involved with open >> source. I am looking for projects that are interested in taking on students. >> The branch will be running an information session and I am hoping to list >> some projects that are willing to mentor students. Is Boost interested? >> >> Thanks, >> Chris De Vries > > Hi Chris, > > I think you'll probably hear something like this from many projects... > Boost is already involved in Google Summer of Code, which on the face of > it seems like a similar program, and takes a great deal of time from > those participating. I can't speak for others, but it seems unlikely > that anyone would have the resources to support two such programs. > > Maybe you have already thought about how to compete with GSoC and have > designed it to be more attractive? If so, it would be good to know the > details. > > Thanks! > > -- > Dave Abrahams > BoostPro Computing > http://www.boostpro.com Hi Dave, My idea is that students will become involved with a project by making some small contributions and then go onto participate in Google Summer of Code. It is still uncertain if GSoC will run in Australia this year. Hopefully we will hear soon. I assume this will not fit in well with the Boost development model where entire modules are proposed, evaluated then developed. Is this assumption correct? I think that working together with other programs (GSoC, etc) will work best, rather than competing against them. I see the IEEE as a means to assist, inform and encourage students to become involved. This will be effective because we can do it in person and on campus. We are also providing free pizza to encourage attendance at our information session. If this program succeeds I hope that it will spread to other student branches. As you have suggested it might be too much load for already strained projects. I will have to wait and see how it goes. Thanks for your feedback. Chris De Vries

2 1

[exception] Incompatibility between boost::throw exception and throw prototype declarations
by vicente.botet 06 Sep '08

06 Sep '08

Hi, As boost::throw_exception can now throw un unspecified exception throgh the use of enable_current_exception, do it is no more possible to use throw declaration in the prototype of any function calling functions that directly or indirectly calls throw_exception. See enable_current_exception declaration in the documentation. namespace boost { template <class T> ---unspecified--- enable_current_exception( T const & e ); } Does it means that we have a interface change of the boost::throw function since it was implemented by the Boost.Exception library on 1.36.0? Best, Vicente

4 8

[interprocess] Just a note of thanks to the developers :)
by Faisal Vali 06 Sep '08

06 Sep '08

I Have been working on some COM components in the windows environment that have required communication across processes. The abstractions the interprocess library provides have greatly simplified my life (as have many of the other libs in boost, and i have been negligent in my thanks). Thank you so much! Faisal Vali, MD, MSc Radiation Oncology Loyola p.s. If this is the incorrect forum for showing appreciation, I apologize

3 5

possible bug introduced in boost function
by Emil Dotchevski 06 Sep '08

06 Sep '08

I have strong suspicions that the changes in boost::function made today introduce a serious bug in the lifetime management of the contained object. I don't have a simple test case to demonstrate it, but a rather complicated use of boost::function which contains shared_ptr in a boost::bind results in incorrect refcount which leads to a crash. Reverting to revision 48607 makes the shared_ptr refcount correct. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

4 5

[review] FSM Library review result
by Martin Vuille 06 Sep '08

06 Sep '08

This is a brief report of the results of the review of Andrey Semashev's Finite State Machines (FSM) library. I want to do justice to the discussions that took place, and will follow-up with a complete summary next week. In spite of a good amount of discussion and an extension of the review period, the number of reviews was smaller than I had hoped for. Nonetheless, I believe that the library received an adequate review and, based on the review comments and other discussions, the FSM library cannot be accepted into Boost at this time. A total of four reviews were submitted, as follows: Andrea Carbone: YES Phil Endecott: NO Jeff Flinn: NO Chris Knight: NO Darryl Green also submitted a mini-review, which did not include an explicit yes or no vote, but expressed doubt about whether the library should be accepted. On the positive side, several people noted that the goals of the library (simplicity and greater performance than Boost.StateCharts) were valid and that such a library was needed in some applications. I personally support this view. I would like to thank Andrey for his efforts in developing the library. I would like to encourage him to pursue the discussions that were begun during this review and perhaps try again with an updated submission. MV

4 3

BOOST_CURRENT_FUNCTION
by Emil Dotchevski 06 Sep '08

06 Sep '08

It appears that BOOST_CURRENT_FUNCTION returns '(unknown)' on sun-5.7, sun-5.8 and sun-5.9, I'm looking at http://www.boost.org/development/tests/trunk/developer/output/Sandia-sun-bo…. Is this a bug, or is BOOST_CURRENT_FUNCTION not possible on that compiler? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

6 12

[spirt] question regarding BOOST_SPIRIT_THREADSAFE and BOOST_SPIRIT_SINGLE_GRAMMAR_INSTANCE
by Robert Ramey 05 Sep '08

05 Sep '08

I've just discovered the existence of these manifest constants in spirit and checked the documentation and code to determine what they do. Of course figuring what spirt code does and how it does is not easy to get right for the casual observer so feel free to correct and any mis-conceptions / conclusions that I 've got. My general conception is that parsing can be consider as various quasi - independent phases. a) specification of grammar - source code preparation b) compiliation c) instantiontion/construction of grammar definition d) usage of c) to parse a text string e) destruction of instance. >From this I want to conclude that phase d) does not change the grammar definition so so that in a multi-threading environment, the invocation of the scoped_lock would be limited to phases c) and e). That is, I want to believe that the following example adapted from the spirit documentation would work: const my_grammar g; // note addition of const if (parse(first, last, g, space_p).full) cout << "parsing succeeded\n"; else cout << "parsing failed\n"; The reason I ask is that the serialization library uses spirit to parse xml archives. Recently, I made changes to make the library thread-safe. I did this without using mutexes/locks by confine all non-const operations to construction and destruction and using static object constructed/destructed at pre-main and post main time time. Although the jury is still out on this, I believe it will make the serialization library thread safe without the need for using threading primitives and libraries. I never realised that spirt wasn't thread-safe. I would like this approach to include xml_archives. So my quesion is: Can I instantiate my xml grammar as a static variable at pre-execution time and permit it to be used by mulitipe threads without locking? Robert Ramey

7 13

[thread] 1.36 thread.hpp compilation problem
by Chris Newbold 05 Sep '08

05 Sep '08

I'm in the process of evaluating Boost 1.36 as a potential upgrade from 1.35, in part to get the critical fixes to Boost.Thread. I've found, however, that something appears to have been broken with the library-level header and the way that it includes all the more-specific headers. My cursory search of the mailing list didn't reveal any previous reports; my apologies if I missed something. Here's my one-line test program: #include <boost/thread.hpp> This compiles cleanly using 1.35, but with 1.36 there are a number of errors related to condition_variable::wait and shared_mutex: In file included from /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/shared_mutex.hpp:16, from /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread.hpp:22, from 136.C:1: /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp: In member function 'void boost::shared_mutex::lock_shared()': /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp:64: error: no matching function for call to 'boost::condition_variable::wait(<unresolved overloaded function type>)' /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/condition_variable.hpp:17: note: candidates are: void boost::condition_variable::wait(boost::unique_lock<boost::mutex>&) /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp: In member function 'bool boost::shared_mutex::timed_lock_shared(const boost::system_time&)': /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp:91: error: no matching function for call to 'boost::condition_variable::timed_wait(<unresolved overloaded function type>, const boost::posix_time::ptime&)' /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/condition_variable.hpp:23: note: candidates are: bool boost::condition_variable::timed_wait(boost::unique_lock<boost::mutex>&, const boost::system_time&) /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/condition_variable_fwd.hpp:50: note: bool boost::condition_variable::timed_wait(boost::unique_lock<boost::mutex>&, const boost::xtime&) /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp: In member function 'void boost::shared_mutex::lock()': /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp:135: error: no matching function for call to 'boost::condition_variable::wait(<unresolved overloaded function type>)' /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/condition_variable.hpp:17: note: candidates are: void boost::condition_variable::wait(boost::unique_lock<boost::mutex>&) /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp: In member function 'bool boost::shared_mutex::timed_lock(const boost::system_time&)': /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp:148: error: no matching function for call to 'boost::condition_variable::timed_wait(<unresolved overloaded function type>, const boost::posix_time::ptime&)' /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/condition_variable.hpp:23: note: candidates are: bool boost::condition_variable::timed_wait(boost::unique_lock<boost::mutex>&, const boost::system_time&) /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/condition_variable_fwd.hpp:50: note: bool boost::condition_variable::timed_wait(boost::unique_lock<boost::mutex>&, const boost::xtime&) /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp: In member function 'void boost::shared_mutex::lock_upgrade()': /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp:199: error: no matching function for call to 'boost::condition_variable::wait(<unresolved overloaded function type>)' /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/condition_variable.hpp:17: note: candidates are: void boost::condition_variable::wait(boost::unique_lock<boost::mutex>&) /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp: In member function 'bool boost::shared_mutex::timed_lock_upgrade(const boost::system_time&)': /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp:211: error: no matching function for call to 'boost::condition_variable::timed_wait(<unresolved overloaded function type>, const boost::posix_time::ptime&)' /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/condition_variable.hpp:23: note: candidates are: bool boost::condition_variable::timed_wait(boost::unique_lock<boost::mutex>&, const boost::system_time&) /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/condition_variable_fwd.hpp:50: note: bool boost::condition_variable::timed_wait(boost::unique_lock<boost::mutex>&, const boost::xtime&) /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp: In member function 'void boost::shared_mutex::unlock_upgrade_and_lock()': /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp:266: error: no matching function for call to 'boost::condition_variable::wait(<unresolved overloaded function type>)' /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/condition_variable.hpp:17: note: candidates are: void boost::condition_variable::wait(boost::unique_lock<boost::mutex>&) -Chris

7 11

[repost][serialization] generic runtime helpers
by joaquin＠tid.es 05 Sep '08

05 Sep '08

Hello, allow me to repost the following lest my first try went unnnoticed: The section on proposed case studies for Boost.Serialization talks about the poosible inclusion of a so-called "generic runtime helper": http://tinyurl.com/6khxns http://www.boost.org/doc/libs/1_36_0/libs/serialization/doc/new_case_studie… which subject I had the pleasure to discuss with Mr. Ramey some time ago. I've got a couple of questions regarding this feature: 1. Is there any tentative release version for getting this included? 2. Is the idea to include the generic runtime helper as part of the core API of an Archive, or will it be just an adaptor? In other words, would the core "Saving Archive" and "Loading Archive" concpets be extended to also feature this runtime helper? FWIW, I'm strongly in favor of having the runtime helper be part of the core Archive concepts: it is my stance that this can be incredibly useful to implement serialization code for types with special lifetime semantics (as is the case with boost::shared_ptr and boost::flyweight) without violating the encapsulation either of the type or of Boost.Serialization. The key and only property of such a runtime helper is its ability to associate an Archive object with a type-dependent helper object, which I see as a very modest, yet highly useful, extension to the Archive concept. Just to exemplify how useful helpers can be, allow me to sketch the serialization process of flyweight<T> as implemented with runtime helpers: * Saving: the helper<flyweight<T> > is just a bag of flyweight<T>s whose elements are *exemplars*. when saving a new flyweight, first we check whether an equivalent flyweight is already present in the helper: if so, the index of the exemplar is output, otherwise, the underlying T associated to the flyweight is saved and the flyweight is added to the helper as a new exemplar. * Loading: again the helper is a bag of flyweight<T>s. When loading a flyweight<T>, we can read either an index or a T object: in the former case we just initialize the flyweight with the corresponding exampler; in the latter case we load the T object, construct a flyweight from it, add it as new exemplar and initialize the loading flyweight with it. This implementation is totally non-intrusive and maximally efficient. An observant reader will also notice that it can be translated almost literally to a serialization scheme for shared_ptr, which shows the potential of the runtime helper feature. Currently, shared_ptr serialization relies on a non-documented adhoc helper, which technically makes it a non-serializable type: promoting the runtime helper to the Archive concept would allow to make shared_ptr a first-class citizen. I also think more types can benefit from this feature when implementing their serialization code. Valid concerns may be raised that extending the Archive concept would break backwards compatibility. However, it is easy to help programmers migrate their user-defined archives to the new concept: just provide a mix-in base class implementing the required functionality, so that if class my_archive { }; models the original Archive concept, just adding the following: class my_archive: public boost::archive::runtime_helper_impl { }; would automatically make my_archive model the new concept. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Re: [boost] Asio and SSL problem
by Berserker 05 Sep '08

05 Sep '08

Thanks for the reply Carlo :) > * when you close and connect again, we use 'lowest_layer()' where you use > 'next_layer()' stream::lowest_layer() is only a wrapper around "next_layer_.lowest_layer()" where, in case of a "basic_socket" as template argument, is: lowest_layer_type& basic_socket::lowest_layer() { return *this; } So there is no difference with: next_layer_type& stream::next_layer() { return next_layer_; } > * stupid one (you never know...): are you catching exceptions on the > caller? :) Sure but I don't think that a stack overflow is a "catchable exception" don't you think :) ? _________________________________________________________________ Cerchi un locale per la serata? Chiedilo a Live Maps! http://maps.live.it/

2 1

Mentoring students
by Chris De Vries 05 Sep '08

05 Sep '08

Hi, My name is Chris De Vries and I am involved with the IEEE student branch at the Queensland University of Technology in Brisbane, Australia [1]. I am organizing a program that encourages students to become involved with open source. I am looking for projects that are interested in taking on students. The branch will be running an information session and I am hoping to list some projects that are willing to mentor students. Is Boost interested? Thanks, Chris De Vries [1] http://ewh.ieee.org/sb/queensland/qut/

2 1

Stacking iterators vs. dataflow
by Phil Endecott 05 Sep '08

05 Sep '08

I just noticed this in the "lifetime of ranges vs. iterators" thread (which I've not really been following): Arno Sch?dl wrote: > rng | filtered( funcA ) > | filtered( funcB ) > | filtered( funcC ) > | filtered( funcD ) > | filtered( funcE ) I thought it worth pointing out the similarity, and also the difference, between this and the proposed dataflow notation. Here, operator| is being used like a shell pipe operator. In dataflow, operator| has a quite different meaning: it's a vertical line, distributing the output of "rng" to the inputs of the funcs in parallel. Confusing, perhaps? Anyway you could presumably write something like rng >>= funcA >>= funcB .... and I would be interested to hear how the two implementations compare. Is it true to say that stacked iterators implement a "data pull" style, while dataflow implements "data push"? I also note that Arno wants to use stacked iterators because this alternative: result = fn1( fn2( fn3( fn4( huge_document ) ) ) ); creates large intermediates and requires dynamic allocation. Again, a framework that allowed buffering of "sensible size" chunks and potentially distributed the work between threads could be a good solution. Phil.

8 19