- Boost - lists.boost.org

[TTI] Why add to boost namespace?
by Noah Roberts 23 Jul '11

23 Jul '11

Why do the macros add templates to the boost::tti namespace rather than the current one? One thing I get from the way MPL create the has_xxx metafunctions is that I can do this: template < typename T > struct obeys_xxx_concept { BOOST_MPL_HAS_XXX_TRAIT_DEF(some_trait) ... etc... enum { value = etc_checks<T>(0).... && has_some_trait<T>::value }; typedef boost::mpl::bool_<value> type; }; That wouldn't work with the TTI library it appears. What does putting the templates in the boost::tti namespace do for me to make up for this loss?

3 2

Can't check out from sandbox
by Noah Roberts 22 Jul '11

22 Jul '11

I want to do some review or at least experimenting with TTI but I can't get it. Every time I try I get this message: Checkout from http://svn.boost.org/svn/boost/sandbox/tti, revision HEAD, Fully recursive, Externals included REPORT of '/svn/boost/!svn/vcc/default': Could not parse chunk size (http://svn.boost.org) There a workaround?

2 2

Boost 1.44.0 - Problem with optional matching
by programmer1 22 Jul '11

22 Jul '11

I'm attempting to match a floating point literal which can contain several optional tokens. Even though the rule succeeds, it doesn't return all the symbols which make up the token. Example Consider the following. Even though the parser succeeds, it returns only "Km" in the match string. Why is that? I expect "-666.0e-45km". std::string phrase = "-666.0e-45km"; std::string val; std::cout << "res: " << parse_number(phrase.begin(), phrase.end(), val) << std::endl; /* prints "1" */ std::cout << val << std::endl; /* prints "km" */ grammar Here is the grammar which I'm trying to express in Spirit. Notice how it is slightly different from the built-in rule "double_" <number> := <decimal> | "INF" | "-INF" | "NaN" <decimal> := ["-"] <digits> ["." <digits>] [<exp>] [<unit>] <exp> := ("e"|"E") ["+"|"-"] <digits> <digits> := <digit> (<digit> | "_")* <digit> := ('0' - '9') <unit> := <unitChar>* <unitChar> := <alpha> | "%" | "_" | "/" | "$" | any char > 128 // see sys::Unit Code namespace qi = boost::spirit::qi; namespace ascii = boost::spirit::ascii; namespace phoenix = boost::phoenix; template <typename Iterator> struct number_grammar : qi::grammar<Iterator, std::string(), ascii::space_type> { number_grammar() : number_grammar::base_type(number, "number") { using qi::lit; using ascii::char_; using qi::digit; using ascii::string; using qi::alpha; using qi::on_error; using qi::fail; using phoenix::construct; using phoenix::val; unitChar = alpha | char_('%') | char_('_') | char_('/') | char_('$') ; // | any char > 128 // see sys::Unit unit = *unitChar ; digits = digit > *( digit | lit('_') ) ; exp = ( char_('e') | char_('E') ) > -( char_('+') | char_('-') ) > digits ; decimal = -char_('-') > digits > -( char_('.') > digits ) > -exp > -unit ; number = string("INF") | string("-INF") | string("NaN") | decimal ; on_error<fail> ( number, std::cout << val("Error! Expecting ") << qi::_4 // what failed? << val(" here: \"") << construct<std::string>(qi::_3, qi::_2) // iterators to error-pos, end << val("\"") << std::endl ); } qi::rule< Iterator, std::string(), ascii::space_type > number; qi::rule< Iterator, std::string() > decimal; qi::rule< Iterator, std::string() > exp; qi::rule< Iterator, std::string() > digits; qi::rule< Iterator, std::string() > unit; qi::rule< Iterator, char() > unitChar; }; template <typename Iterator> bool parse_number(Iterator first, Iterator last, const std::string& val) { using qi::phrase_parse; using ascii::space; number_grammar<Iterator> grammar; bool r = phrase_parse ( first, /*< start iterator >*/ last, /*< end iterator >*/ grammar, /*< the parser >*/ space, /*< the skip-parser >*/ val ); std::cout << val << std::endl; if (first != last) // fail if we did not get a full match return false; return r; } -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-1-44-0-Problem-with-optional-match… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 2

[TR1] clang patch
by Jürgen Hunold 22 Jul '11

22 Jul '11

Hi John, the current clang (version 3.0 (trunk 135764)) is still emulating gcc-4.2.1 which leads to a lot of the tr1-tests failing with: boost/boost/tr1/detail/config_all.hpp:158:12: fatal error: '../4.2.1/utility' file not found # include BOOST_TR1_STD_HEADER(utility) ^ boost/boost/tr1/detail/config_all.hpp:100:44: note: expanded from: # define BOOST_TR1_STD_HEADER(name) <../__GNUC__.__GNUC_MINOR__.__GNUC_PATCHLEVEL__/name> ^ 1 error generated. if your installed gcc is not 4.2.1. The attached patch fixes this by introducing a special case for clang. This fixes all but eight tr1-tests for clang trunk. Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

3 3

[iostreams] gcc visibility support patch
by Jürgen Hunold 22 Jul '11

22 Jul '11

Hi, I've found some patches for https://svn.boost.org/trac/boost/ticket/2114 This one enables visibility support for Boost.IOStreams For more information, please see http://gcc.gnu.org/wiki/Visibility Tested locally for too long. Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

1 0

[Thread] Assertion on mutex when using multiple threads and mutexes
by Tim van den Kerkhof 22 Jul '11

22 Jul '11

Hi all, As a part of a project I'm writing a logger function. This logger function sends an e-mail when the program wants to log something. Since it has happened that the SMTP server was non responsive, I've decided to do the sending of the mails in a separate thread. This thread reads messages from an std::deque which is filled by the logging function. The thread is setup as follows: while (!boost::this_thread::interruption_requested()) { EmailItem emailItem; { boost::unique_lock<boost::mutex> lock(mMutex); while (mEmailBuffer.empty()) mCond.wait(lock); bufferOverflow = mBufferOverflow; mBufferOverflow = false; nrOfItems = mEmailBuffer.size(); if (nrOfItems > 0) { emailItem = mEmailBuffer.front(); mEmailBuffer.pop_front(); } } if (nrOfItems > 0) { bool sent = false; while(!sent) { try { ..... Do something with the message ..... { boost::this_thread::disable_interruption di; boost::lock_guard<boost::mutex> lock(mLoggerMutex); mLogFile << emailItem.mMessage << std::endl; } sent = true; } catch (const std::exception &e) { // Unable to send mail, an exception occurred. Retry sending it after some time sent = false; boost::this_thread::sleep(boost::posix_time::seconds(LOG_WAITBEFORE_RETRY)); } } } } The function log() adds a new message to the deque (mEmailBuffer) as follows: { boost::lock_guard<boost::mutex> lock(mMutex); mEmailBuffer.push_back(e); mCond.notify_one(); } When the main program exits, the destructor of the logger object is called. This is where it goes wrong, the application crashes with an error: /usr/include/boost/thread/pthread/mutex.hpp:45: boost::mutex::~mutex(): Assertion `!pthread_mutex_destroy(&m)' failed. The destructor merely calls an interrupt on the thread and then joins it: mQueueThread.interrupt(); mQueueThread.join(); In the main program, I use multiple different classes which make use of boost threading and mutex as well, could this cause this behaviour? Not calling the destructor of the logger object results in no errors, as does using the logger object and not doing anything else. My guess is I am doing something very wrong, or there is a bug in the threading library when using multiple threads divided over several classes. Does anyone have a idea what the reason for this error might be? Regards, Tim van den Kerkhof

1 0

[date_time] gcc visibility support patch
by Jürgen Hunold 22 Jul '11

22 Jul '11

Hi, I've found some patches for https://svn.boost.org/trac/boost/ticket/2114 This one enables visibility support for Boost.DateTime For more information, please see http://gcc.gnu.org/wiki/Visibility Tested locally for too long. Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 2

[C++0x] Emulate C++0x char16_t, char32_t, std::u16string, and std::u32string
by Beman Dawes 22 Jul '11

22 Jul '11

I'm starting to fold in Boost.Filesystem support for the new C++0x character types. Support is emulated for compilers and standard libraries not currently supporting the 0x features. The emulation is working fine, with tests passing on Windows for GCC 4.5 and 4.6, and VC++ 8, 9, and 10. Haven't tested on non-Windows systems yet. This is the same emulation approach Microsoft ships in VC++ 10. It seems to me that all Boost libraries that want to emulate these 0X features should use the a unified approach. Otherwise we could get into a situation where libraries A and B worked fine in isolation, but had symbol or ODR clashes when used together. The header I'm using is attached. I propose to place this in <boost/string_0x.hpp> rather than, say, <boost/filesystem/detail/string_0x.hpp>, and providing a simple doc page. Does this make sense? --Beman

6 15

[program_options] gcc visibility support patch
by Jürgen Hunold 22 Jul '11

22 Jul '11

Hi Volodya, I've found some patches for https://svn.boost.org/trac/boost/ticket/2114 This one enables visibility support for program_options. Tested locally for too long. Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

[Review] Lockfree review starts today, July 18th
by Hartmut Kaiser 22 Jul '11

22 Jul '11

Hi all, The review of Tim Blechmann's Boost.Lockfree library starts today, July 18th 2011, and will end on July 28th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! ----------------------------------------------------- About the library: Boost.Lockfree provides implementations of lock-free data structures. Lock-free data structures can be accessed by multiple threads without the necessity of blocking synchronization primitives such as guards. Lock-free data structures can be used in real-time systems, where blocking algorithms may lead to high worst-case execution times, to avoid priority inversion, or to increase the scalability for multi-processor machines. The following data structures are provided: - boost::lockfree::fifo, a lock-free fifo queue - boost::lockfree::stack, a lock-free stack - boost::lockfree::atomic_int, an atomic integer class The library is accessible from here: http://tim.klingt.org/boost_lockfree.tag.gz. Boost.Lockfree depends on C++0x atomics. They are not well supported with current compilers yet. For this reason Boost.Lockfree depends on the *unreviewed* Boost.Atomic library, that emulates C++0x atomics for C++98. This review is about Boost.Lockfree and not about Boost.Atomic, although it is included in the tarball and the git repository. If Boost.Lockfree will be accepted, it won't be merged into trunk before Boost.Atomic is accepted. --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager

9 17