- Boost - lists.boost.org

Interest in mmapped container library
by Dmitry Prokoptsev 25 Sep '12

25 Sep '12

Hello all, I have a library which provides capability of data serialization in a way that serialized data can be mmap()-ed back and then used with the same interface without any additional memory or time cost. A short usage example: https://gist.github.com/3656916 Is there an interest in such library? -- Dmitry Prokoptsev

2 2

Boost:Foreach Werror flag's problem in foreach.hpp
by GAURAV GUPTA 25 Sep '12

25 Sep '12

Hi , While using Boost (ver 1.51.0) file "foreach.hpp" I am getting following errors: Boost/1.51/Inc/boost/foreach.hpp:454:5: error: cast from 'char*' to 'std::vector<std::pair<std::basic_string<char>, std::basic_string<char> > >*' increases required alignment of target type [-Werror=cast-align] cc1plus: all warnings being treated as errors I need to use "Werror" flag in my application. Any solution for this problem? -- Regards, Gaurav

3 2

[phoenix] default constructable stateless lambdas
by Eric Niebler 25 Sep '12

25 Sep '12

While answering a question about Phoenix on stackoverflow[^1], I discovered that Phoenix lambda types are default-constructable, so long as all the terminals are also default constructable. That's handy when the terminals are stateless. Can it (the default-constructability) be relied on? It doesn't appear to be documented. C++11 lambdas have the nice property that stateless ones are implicitly convertible to raw function pointers. This can be implemented for Phoenix if we can rely on the default-constructability of Phoenix lambda types. In my stackoverflow answer I show how. It'd be pretty cool if this were a standard part of all Phoenix lambdas. Is there interest? Incidentally, I think it's really, really cool that Phoenix allows this kind of extensibility. It's a very nice example of the benefits of the introspection capabilities built into Phoenix. Perhaps this could be worked into the docs somehow? [^1]: http://stackoverflow.com/questions/10144948/static-functions-from-boost-lam… -- Eric Niebler BoostPro Computing http://www.boostpro.com

4 6

[config] gcc-4.4 and BOOST_NO_SFINAE_EXPR
by Eric Niebler 25 Sep '12

25 Sep '12

As part of our work to make result_of sfinae-friendly, Daniel Walker and I have discovered that gcc-4.4 doesn't have very good support for generalized sfinae for expressions. Can we get BOOST_NO_SFINAE_EXPR defined for it? Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

4 9

[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