- Boost - lists.boost.org

[General] Treat narrow strings as UTF-8 (compilation flag)
by Yakov Galka 23 Jul '11

23 Jul '11

Hello All, About half a year ago there was a long discussion titled "Always treat std::strings as UTF-8". The only objection to the proposal was that making an instant switch by assuming UTF-8 by default will give surprising results to those who're unaware of the convention (or prefer using legacy encodings instead of UTF-8). This applies almost only to Windows developers. However, there are already many projects and organizations that switched to UTF-8 even for Windows programming. The company I work in is one of them. Nowadays: ========== All the libraries that accept narrow strings assume the system encoding by default. * filesystem::path — Can be configured through static imbue() function. * system_error_category (windows error description), interprocess (object names)... more? — Don't support Unicode at all. They use the narrow API on Windows. * program_options — Assumes UTF-8 for internal data (Good!), but uses system encoding for paths (parse_config_file) and for environment variables (Bad...) . Note that, e.g. path::imbue(), is a painful solution for two reasons: Any global state initialization is problematic in dynamically-linked, multi-threaded systems (like the one I'm maintaining now). In such cases a compile time configuration is more attractive. I really don't want to have such a function in each boost library (can be solved by having a global boost::imbue though). Proposal: ======== Add a compile-time configuration flag that causes boost to treat all narrow strings as UTF-8. The flag will be off by default. For example, in filesystem it's a matter of setting `codepage` to CP_UTF8 in just two places. Rationale: ========== Those who are ready to move to the UTF-8 future, they can do it by simply setting a compilation flag.. Those who don't care about Unicode correctness are not affected by the addition. There won't be any complaints to boost, like: "Hey! I use boost with these libraries and it doesn't work. Your encoding is wrong!". -- Yakov Galka

4 5

[Config] Cray compiler
by Marshall Galbraith 23 Jul '11

23 Jul '11

Hello, I am using a few boost libraries for a research code that I am developing. I currently have access to a Cray XE6 machine (http://www.cray.com/Products/XE/Specifications.aspx) along with the Cray Compiler Environment. I would like to compile my code with the Cray compiler so I can use their Cray PAT utilities for performance testing. I was able to generate a user.hpp file for the Cray compiler, but it is automatically generated and I am not verse enough with the compilation of boost to ensure that it is correct. If there is any interest in developing a Cray configuration for compiling boost, I am more than interested in helping. I can also get in touch with the Cray compiler developers for assistance with any compiler issues. Looking through the history of this mail list there was an initiative to do this back in 2003, but it did not seem to come to fruition. Thank you for all your help, Marshall Galbraith

2 1

[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