September 2012 - Boost - lists.preview.boost.org

[trac] Add result_of component
by Michel Morin 24 Sep '12

24 Sep '12

result_of does not have a trac component. But I think it's worth adding result_of component. Here is maintainer's information: [maintainer] djwalker [name] Daniel Walker Regards, Michel

2 4

[locale] Normalization and transformation
by Denis Arnaud 23 Sep '12

23 Sep '12

Hi, following is a sample program playing with text conversion features of Boost.Locale (Boost version 1.48.0 on Linux Fedora 17), as seen in the documentation (http://unicode.org/reports/tr15/#Norm_Forms and http://www.boost.org/doc/libs/1_51_0/libs/locale/doc/html/index.html) ___________________________________________________________ #include <boost/locale.hpp> int main() { // Get the global localisation backend boost::locale::localization_backend_manager locBEMgr = boost::locale::localization_backend_manager::global(); // Select ICU backend as default locBEMgr.select ("icu"); // Set this backend globally boost::locale::localization_backend_manager::global (locBEMgr); // Create a generator that uses this backend. boost::locale::generator locGen (locBEMgr); // Create locale generator with the system default locale std::locale::global (locGen ("")); // Test string with accents (french word for "side") std::string sideFR ("Côté"); // Test the Boost Locale string conversions std::cout << "Original: " << sideFR << std::endl <<"Upper " << boost::locale::to_upper (sideFR) << std::endl <<"Lower " << boost::locale::to_lower (sideFR) << std::endl <<"Title " << boost::locale::to_title (sideFR) << std::endl <<"Fold " << boost::locale::fold_case (sideFR) << std::endl << "Normalised - [NFD]: " << boost::locale::normalize (sideFR, boost::locale::norm_nfd) << "; [NFC]: " << boost::locale::normalize (sideFR, boost::locale::norm_nfc) << "; [NFKD]: " << boost::locale::normalize (sideFR, boost::locale::norm_nfkd) << "; [NFKC]: " << boost::locale::normalize (sideFR, boost::locale::norm_nfkc) << std::endl; return 0; } ___________________________________________________________ The output is: _____________________________________________________ Original: Côté Upper CÔTÉ Lower côté Title Côté Fold côté Normalised - [NFD]: Côté; [NFC]: Côté; [NFKD]: Côté; [NFKC]: Côté ____________________________________________________ Apparently, there is no difference in the normalization forms, whatever method is used (NFC, NFD, NFKC, NFKD). I would expect that NFD and NFKD would produce a different result. But maybe my (UTF8-based) Linux terminal recomposes automatically the letters and accents, so that we do not see the difference? Or is it a feature of Boost.Locale, which I overlooked? Let me state my goal. I use Xapian (http://xapian.org/docs/) as a full-text matching engine, and I feed it with texts of various languages and scripts, all in UTF8. Xapian will typically match keywords with the same forms and cases; in other words, I cannot choose or influence the collation algorithm (http://www.unicode.org/reports/tr10/) which corresponds to the third or fourth in Xapian (AFAIU). To give a sample, if the "Côté" word has been indexed by Xapian, "cote" will not match with it. So, I would like Xapian to index both forms ("Côté" and "cote"), so that both forms match. When a user gives me a string to match against the index, I will first try to match the string itself, then transform it (http://www.icu-project.org/icu-bin/translit) and try to match the transformed version. So, my question is: Is Boost.Locale capable of transforming Unicode strings, for instance to remove accents? A good example is provided by the first answer to the StackOverflow question: http://stackoverflow.com/questions/144761/how-to-remove-accents-and-tilde-i… In other words, I would like to apply the "NFD; [:M:] remove; NFC" transformation, as is possible with the ICU library. The following is a code sample showing how to do that: ____________________________________________________ // ICU #include <unicode/translit.h> #include <unicode/unistr.h> #include <unicode/ucnv.h> int main() { // Create a Normalizer UErrorCode status = U_ZERO_ERROR; const char* lNormaliserID = "NFD; [:M:] Remove; NFC;"; lNormaliser = Transliterator::createInstance (lNormaliserID, UTRANS_FORWARD, status); // Register the Transliterator Transliterator::registerInstance (lNormaliser); UnicodeString myString ("Côté"); lNormaliser->transliterate (myString); std::cout << "Normalized version without accents" << toUTF8String (lQueryString) << std::endl; return 0; } ____________________________________________________ Do not hesitate if you have suggestion, feedback, work around... Kind regards -denis

1 1

[thread] patch to suppress msvc warnings
by Jürgen Hunold 22 Sep '12

22 Sep '12

Hi Vicente, I get lots of noisy warning from win32/thread_data.hpp Example: boost/thread/win32/thread_data.hpp(90) : warning C4251: 'boost::detail::thread_data_base::thread_handle' : class 'boost::detail::win32::handle_manager' needs to have dll-interface to be used by clients of struct 'boost::detail::thread_data_base' Patch suppressing those attached. Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 3

[lockfree] some msvc fixes
by Jürgen Hunold 22 Sep '12

22 Sep '12

Hi Tim, please find a patch attached that fixes. a) fixes for min-max-guideline violations (triggers if windows.h is include and NOMINMAX is not defined) b) some conversion warnings in the tests. Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 1

Possible header error on boost/geometry/algorithms/area.hpp
by chedi toueiti 22 Sep '12

22 Sep '12

Hi, This is my first email on the list, and I hope I'm mistaking this, but while compiling mapnik with the latest boost revision from svn repo (trunk rev 80625), I got this error: /home/osm/boost-trunk/boost/geometry/algorithms/area.hpp:31:49: error: boost/geometry/geometries/variant.hpp: No such file or directory So I changed the file like as I thought fit: Index: boost/geometry/algorithms/area.hpp =================================================================== --- boost/geometry/algorithms/area.hpp (revision 80625) +++ boost/geometry/algorithms/area.hpp (working copy) @@ -28,7 +28,7 @@ #include <boost/geometry/core/ring_type.hpp> #include <boost/geometry/geometries/concepts/check.hpp> -#include <boost/geometry/geometries/variant.hpp> +#include <boost/variant/variant.hpp> #include <boost/geometry/algorithms/detail/calculate_null.hpp> #include <boost/geometry/algorithms/detail/calculate_sum.hpp> and now everything compiles fine, so I hope this will be helpful. -- *Chedi Toueiti* * Due to the constant fluctuation in customer personalities, we cannot be responsible for the mental stability of any one member of our staff. ** My opinions may have changed, but not the fact that I am right. *** I always try to go the extra mile at work, but my boss always finds me and brings me back.

1 0

[coroutine] Experimenting with interfaces
by Eugene Yakubovich 21 Sep '12

21 Sep '12

I've been playing around with coroutines by trying to solve some "real" problems (in pseudo C++, without compilation). One thing that I noticed is that symmetry is important. For example, for a chess simulation: class move { ... }; class board { ... }; // Each player has his own instance of the board class void player(coroutine<move(move)> opponent, move his, board brd) { while( !brd.is_mate() ) { brd.opponent_move(his); move mine = ...; brd.my_move(mine); his = opponent(mine); } } void white(coroutine<move(move)> opponent) { board brd(WHITE); move mine = ...; brd.my_move(mine); his = opponent(mine); player(opponent, his, board); } void black(coroutine<move(move)> opponent, move his) { board brd(BLACK); player(opponent, his, brd); } void play() { coroutine<move(move)> b(black); white(b); } It's very convenient that "both sides" have the same type. It makes it easy to write the common player() routine. Another thing to note is that the coroutine function returns void. I found that to basically be always true -- I never needed to use the 'return' to pass back the last value. Like the next example shows, it's also very convenient to have stack unwinding as running the coroutine to completion is not always natural. In the example above, coroutine<move(move)> has a coroutine function with signature void(move). In some cases, it's even more convenient to have a void() signature as in the following example implementing a TCP server using blocking sockets. struct request { ... }; struct reply { ... }; bool exit = false; // set to 'true' by Ctrl+C handler void server(coroutine<reply(request)> c, unsigned short port) { socket ls; ls.listen(port); while( !exit ) { socket s = ls.accept(); while( !exit ) { request req = s.recv(); reply rep = c(req).get(); s.send(rep); if( rep == "logout" ) break; } } } void run() { coroutine<reply(request)> srv(std::bind(server, 2121)); request req = srv.get(); while ( !exit ) { reply rep = ...; if( srv(rep) ) req = srv.get(); } } Also, in the first example, coroutine::operator() returned T (like fn call) but this example required the use of get(). The function call way (op() returns T) is also convenient since it allows one to write code that works generically with coroutines or functions: template <typename C> void timer(C c, chrono::seconds interval) { while( interval != chrono::seconds::zero() ) { this_thread::sleep_for(interval); interval = c(interval); } } chrono::seconds tick(chrono::seconds last_interval) { std::cout << "tick" << std::endl; return last_interval; } // use with function timer(tick, chrono::seconds(1)); // use with coroutine coroutine<chrono::seconds(chrono::seconds)> c( [](coroutine<chrono::seconds(chrono::seconds)> c, chrono::seconds i) { timer(c, i); } ); chrono::seconds s = c(chrono::seconds(1)); s = c(2*s); s = c(3*s); s = c(5*s); I'm not sure what this means for the best interface but I did want to share these thoughts and examples. Regards, Eugene

3 7

[test] Trunk broken: What happened to test_exec_monitor?
by John Maddock 21 Sep '12

21 Sep '12

Testing on Trunk is apparently broken as the test_exec_monitor target has been removed from Boost.Test Trunk as of revision #74642. A quick grep shows 22 Jamfiles and over 200 targets dependent upon this. Whats happened? John.

14 68

[coroutine] interface suggestion
by Oliver Kowalke 21 Sep '12

21 Sep '12

I forgot a suggestion made by Vicente: 5.a coroutine<>::caller_t provides function bind() which must be called after coroutine::caller_t::yield() returned in order to get the parameters int f( caller_t & c, strg & s, int x) { c.yield( 7); // alternative c( 7) c.bind( s, x); // s and x will contain new values given by caller } alternative: because the user could forget to invoke bind(): int f( caller_t & c, strg & s, int x) { c.yield( 7, s, x); // alternative c( 7, s ,x) } Oliver

3 18

: [coroutine][review] not really a review
by Robert Ramey 21 Sep '12

21 Sep '12

I took a cursory look at the coroutine (or is it context) documentation. Is this all there is? It's really inadequate even to evaluate the library - much less use it for anything. I very much like Giovani's implementation and used in at least one other project. I don't remember why it wasn't accepted - not that it matters now. I would like to request that all the documentation, examples, etc. from the previous package be folded into the the current one - should it be accepted. This facility is 20 years overdue - I know this as I had to role my own 20 years ago! It's also foreign to many programmers who could benefit from it. It must come with motivating documentation to be worthwhile. Robert Ramey

1 0

Timer & Boost.Test incompatibility
by Craig Henderson 20 Sep '12

20 Sep '12

Hi, I am starting a new project. I am using boost::timer::cpu_timer from boost/timer/timer.hpp and Boost.Test When I include boost/test/included/unit_test.hpp in my unit test suite, I get compilation errors where boost::timer is declared as a class where previously it's defined as a namespace: boost/timer.hpp(45): error C2869: 'boost::timer' : has already been defined to be a namespace boost/test/impl/framework.ipp(153): error C2882: 'timer' : illegal use of namespace identifier in expression boost/test/impl/framework.ipp(153): fatal error C1903: unable to recover from previous error(s); stopping compilation Environment: Boost 1.51.0 MSVC 2012 Windows 7 Is this a known conflict? Is there any workaround? Thanks -- Craig

4 5