- Boost - lists.boost.org

[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

binary operator raits
by frederic.bron＠alcan.com 05 Sep '08

05 Sep '08

I have just commited new traits in the sandbox (sandbox/type_traits) to know if a type is comparable or not. I have included tests but could not make bjam and quickbook run together so I have no documentation to commit. The names of the traits are based on standard header <functional>: is_less_comparable<T>, is_less_equal_comparable<T>, is_greater_comparable<T>, is_greater_equal_comparable<T>, is_ equal_to_comparable<T> and is_not_equal_to_comparable<T>. Some comments about these traits: - I was not able to remove the warnings, - the traits inherits from true_type is the operator exists, however, I am not sure if we should return true if the binary operator does not return a type convertible to bool F. Bron Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.

1 0

Asio and SSL problem
by Berserker 05 Sep '08

05 Sep '08

I tried to post this problem in the asio mailing list but I hadn't any feedback, so I'm reporting it here with the hope that someone can help me. I have a "stack overflow" problem with the following code (using boost 1.36): void test_handshake(const std::string &host, const std::string &cert) { boost::asio::io_service service; boost::asio::ssl::context sslContext(service, boost::asio::ssl::context::sslv23); sslContext.set_verify_mode(boost::asio::ssl::context::verify_peer); sslContext.load_verify_file(cert); boost::asio::ip::tcp::resolver resolver(service); boost::asio::ip::tcp::resolver::iterator endpoint_iterator = resolver.resolve(boost::asio::ip::tcp::resolver::query(host, "443")); boost::asio::ip::tcp::resolver::iterator end; boost::asio::ssl::stream<boost::asio::ip::tcp::socket> sslSocket(service, sslContext); boost::system::error_code error = boost::asio::error::host_not_found; while(error && endpoint_iterator != end) { sslSocket.next_layer().close(); sslSocket.next_layer().connect(*endpoint_iterator++, error); } if(error) throw boost::system::system_error(error); sslSocket.handshake(boost::asio::ssl::stream_base::client); // bla bla } When I call this function with a valid certificate for the host I have no problems, but when I pass a "custom" cerificate (not valid for the host specified) it results in a stack overflow error instead of throwing an exception as I expected... This example works: test_handshake("sourceforge.net", "cacerts.pem"); // grab cacerts.pem from here for example: http://www.cs.fsu.edu/~engelen/soapcacerts.html This causes, as I said, a stack overflow instead of an exception: test_handshake("sourceforge.net", "ca.pem"); // ca.pem was taken from the asio examples Plz help P.S.: is anyone using asio with ssl? It's very strange that nobody has reported this problem... _________________________________________________________________ Cerchi un locale per la serata? Chiedilo a Live Maps! http://maps.live.it/

2 1

Boost::log query
by Rajpal Dangi 05 Sep '08

05 Sep '08

While using rotating text file as stream, is it possible to keep most recent log file name same all the time? Currently what I observe is 'N' keeps incrementing and have to manually find out the most recent file. Also, is there some way to print severity in log file without explicitly passing it as part of message i.e. BOOST_LOG_SEV(my_logger, CRITICAL) Thanks

2 5

[testing] How not to mark up explicit failures
by David Abrahams 05 Sep '08

05 Sep '08

https://svn.boost.org/trac/boost/ticket/2258 describes a problem with explicit failure markup that I suspect is not atypical. I believe we need to establish some ground rules for markup that ensure * Boost problems don't pass unnoticed * there is a uniform standard for interpreting test results across libraries * "non-Boost problems" and non-problems don't add alarm bells for people reading test results You can view the markup in question here: https://svn.boost.org/trac/boost/browser/trunk/status/explicit-failures-mar… Aside from the specifics in the ticket, the following problems jump out at me just from looking at that XML: * even on compilers that do support nonstandard calling conventions, failures in these tests will never be flagged as problematic * even on compilers that don't support nonstandard calling conventions, these tests will fail and add useless noise to the chart. I can think of a few general principles and practices that will prevent such problems: * Boost regression tests should test the functionality of code that is expected to work, not to test the capabilities of the platform or C++ implementation. There is a place for capability testing, but it needs to be segregated from regular regression tests somehow. If/when we move to using CMake globally, capability tests should take place in its configure stage. In the meantime, such tests must be kept out of Boost regression testing. * Tests that do not apply to a given compiler or platform should ideally not be run on that compiler. * If we can't find a way to avoid running the test at all, the test should be written to trivially succeed on that compiler or platform. * Test annotation wildcards should be written restrictively so that they only match the compilers/platforms to which they apply. This is probably just a start; I'd like to hear other ideas. I intend that this thread will result in an official Boost policy for test annotation. Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 0