- Boost - lists.boost.org

[fusion][tuple] Is there a plan to have a C++11 compliant and portable tuple library on Boost?
by Vicente J. Botet Escriba 24 Sep '12

24 Sep '12

Hi, In order to implement some features in Boost.thread I need a tuple that supports move semantics for its arguments. I see that there is an effort to provide move semantics when rvalue references are supported by the compiler. Is there a plan to have a C++11 compliant tuple library on Boost that uses the Boost.Move library on compilers that don't support rvalue references? Best, Vicente

4 5

(no subject)
by Davlet Panech 24 Sep '12

24 Sep '12

http://yoga-island.ru/wp-content/plugins/akismet/google.html?hi=vby.jdg&fxc…

1 0

[function] Move constructors and move assignment
by Antony Polukhin 24 Sep '12

24 Sep '12

Hi, There is a patch in ticket #7330, that adds move semantics to Boost.Function. It looks pretty trivial, so if there will be no objections, I'll commit it to trunk at the end of next week. -- Best regards, Antony Polukhin

2 3

[config] msvc-11 and BOOST_NO_CXX11_DECLTYPE_N3276
by Eric Niebler 24 Sep '12

24 Sep '12

Houston, we have a problem.... I've been grappling with a regression in proto due to the use of decltype in boost::result_of on msvc-11. I've concluded that msvc's support for N3276 is just not up to the task. The details are in the following bug report: https://connect.microsoft.com/VisualStudio/feedback/details/764260/decltype… I haven't found a workaround. I'm worried about downstream breakage when 1.52 is released. My suggestion: define BOOST_NO_CXX11_DECLTYPE_N3276 for msvc-11 and live with TR1 result_of for a bit longer. <sigh> -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 2

[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