- Boost - lists.boost.org

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