February 2014 - Boost - lists.preview.boost.org

Library metadata
by Daniel James 17 Mar '14

17 Mar '14

Hi, I'm starting to add metadata to modules for updating the website, and hopefully other uses in the future. I added the metadata to Boost.Unordered and Boost.Functional to give you an idea of what this will look like: https://github.com/boostorg/functional/tree/develop/meta https://github.com/boostorg/unordered/tree/develop/meta You can see several libraries listed in the Boost.Functional file. I'll write some documentation soon, but it should be fairly easy to understand. I basically took what was in the website library list and split it up into modules. Quick summary of the fields: key - Used to be the website to identify each library. Don't change it, or the website will think it's a new library. boost-version - The version in which the library was released. name - The name of the library. authors - The authors of the library - will probably add a 'maintainers' field later. description - Library description - this is used in the library list, so keep it short. std-proposal - Is the library proposed for the standard. std-tr1 - Is the library part of TR1. category - The categories the library belongs to. one element for each category. The documentation will include a list of available categories. documentation - Path to the documentation. The documentation field is optional. If it isn't included, it'll use the default path: /libs/module-name/. If it is included, relative paths are resolved relative to the module directory, absolute paths from boost root - although I'd suggest you always use a path within the module, and if there's only a single library in a module, use the default path. This isn't the final format - I think the standards status fields could do with an overhaul to support C++11 etc. You also don't need to write the initial files yourself, I'll generate them and create pull requests once this is settled. Let me know what you think. thanks, Daniel

8 15

[GSoC] pipelines questions
by Thaler Benedek 06 Mar '14

06 Mar '14

Hi, I'm interested in the Boost.Pipelines proposal of GSoC 2014. [0] I'd like to ask the stakeholder (Vicente J. Botet Escriba ?) the following: * Is this supposed to be built from scratch or rather to be some kind of improvement over the already existing google implementation? [1] * If the former is true, should be n3534 [2] considered as a strict requirement or as a vague suggestion? * If the later is true, which features should be the main distinctive ones? I think about things like using Boost libraries (e.g: Boost.Atomic) instead of custom solutions, cross platform support, comply to Boost coding standard, etc. Are there any areas of improvement identified in the reference implementation? * I understand it might take quite a long time for a proposal to make it to Boost, therefore it's not a requirement. Is there any objective milestone that a successful project should reach anyway? Thanks, Benedek [0]: https://svn.boost.org/trac/boost/wiki/SoC2014#Boost.Pipelines [1]: https://code.google.com/p/google-concurrency-library/source/browse/include/… [2]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3534.html#Proposal

3 4

[signals2] Test failure in C++11 (trivial fix for incorrect usage of boost::optional)
by Ben Pope 06 Mar '14

06 Mar '14

I have the following errors: "clang++-3.4" -c -x c++ -std=c++11 -stdlib=libc++ -O0 -g -fno-inline -Wall -g -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_NO_AUTO_LINK=1 -I".." -o "/home/ben/development/boost/test/build/results/boost/bin.v2/libs/signals2/test/signal_test.test/clang-linux-3.4~c11_libc++/debug/link-static/signal_test.o" "../libs/signals2/test/signal_test.cpp" ../libs/signals2/test/signal_test.cpp:32:16: error: invalid operands to binary expression ('boost::optional<int>' and 'int') if(max == false) max = *first; ~~~ ^ ~~~~~ "clang++-3.4" -c -x c++ -std=c++11 -stdlib=libc++ -O0 -g -fno-inline -Wall -g -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_NO_AUTO_LINK=1 -I".." -o "/home/ben/development/boost/test/build/results/boost/bin.v2/libs/signals2/test/track_test.test/clang-linux-3.4~c11_libc++/debug/link-static/track_test.o" "../libs/signals2/test/track_test.cpp" ../libs/signals2/test/track_test.cpp:36:14: error: invalid operands to binary expression ('boost::optional<int>' and 'int') if(max == false) Richard smith explains the problem here: http://llvm.org/bugs/show_bug.cgi?id=18180#4 "OK, I see what's happening -- in Clang 3.3 and GCC 4.8, 'false' is being treated as a null pointer constant. boost::optional implicitly converts to an "unspecified-bool-type" that happens to be a pointer-to-member type, and thus can be compared against a null pointer constant via the built-in operator!=(pointer-to-member, pointer-to-member) overload. In C++11 onwards, 'false' isn't a null pointer constant any more, so this comparison is no longer valid. Clang 3.3 and GCC 4.8 don't implement that rule; Clang 3.4 does." The trivial fix is to change the if statements at: ../libs/signals2/test/signal_test.cpp:32:16: ../libs/signals2/test/track_test.cpp:36:14: to if(!max) rather than if(max == false). Ben

7 19

libcpp.hpp always defines BOOST_NO_CXX11_HDR_ATOMIC
by Peter Dimov 05 Mar '14

05 Mar '14

The libc++ config header, libcpp.hpp, always defines BOOST_NO_CXX11_HDR_ATOMIC, but the libc++ that - I presume - ships with "Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)" appears to have a functional <atomic>.

6 22

Formal review request: Boost.Mixin
by Borislav Stanimirov 05 Mar '14

05 Mar '14

Hello, I'd like to request a formal review of Boost.Mixin. Code is here: https://github.com/iboB/boost.mixin Documentation is here: http://ibob.github.io/boost.mixin/ In short, the library allows you to dynamically compose and mutate polymorphic types from existing C++ classes. Thanks, -- Borislav

2 3

DRYing BOOST_FUSION_ADAPT_STRUCT with decltype/Boost.TypeOf ?
by Damien Buhl 05 Mar '14

05 Mar '14

Hi dear Boost Fusion developers, I was asking myself if there were already plan to improve BOOST_FUSION_ADAPT_STRUCT to benefit from C++11 features like decltype ? This would be interesting to avoid the risk encountered that the types definitions can get out-of-sync. And would avoid typing type declarations twice. Currently there is BOOST_FUSION_DEFINE_STRUCT to avoid repeating the type information for each field. However this is something that makes most developer I know unhappy, as it obliges to modify the readable C++ aggregate types definition (i.e. Could be public headers) with this macro. Then there is the nice choice of BOOST_FUSION_ADAPT_STRUCT which obliges retyping the type and adds the risk that some field type information could get out-of-sync between the struct definition and the BOOST_FUSION_ADAPT_STRUCT listing. I think it would be valuable to add macros that would enable to select the fields that we want to adapt to a Random Access Sequence without requiring to repeat the type information. I would find more comfortable to write the example provided here http://www.boost.org/doc/libs/1_55_0/libs/fusion/doc/html/fusion/adapted/ad… as follow : namespace demo { struct employee { std::string name; int age; }; } // demo::employee is now a Fusion sequence BOOST_FUSION_ADAPT_STRUCT_EXT( demo::employee, (name) (age)) And a naïve implementation of BOOST_FUSION_ADAPT_STRUCT_EXT could be: #include <boost/typeof/typeof.hpp> #include <boost/fusion/include/adapt_struct.hpp> #include <boost/preprocessor/seq/for_each.hpp> #define ATTRIBUTE_DEFINITION(r, data, elem) \ (BOOST_TYPEOF(data::elem), elem) \ #define BOOST_FUSION_ADAPT_STRUCT_EXT(NAME, ATTRIBUTES) \ BOOST_FUSION_ADAPT_STRUCT(NAME, \ BOOST_PP_SEQ_FOR_EACH(ATTRIBUTE_DEFINITION, NAME, ATTRIBUTES)) #endif The same could certainly be achieved for BOOST_FUSION_ADAPT_TPL_STRUCT, while I didn't check. Thanks for the really great job done in Boost.Fusion. Cheers, -- Damien Buhl alias daminetreg

3 7

[testing][teeks99] Missing headers in boost checkout
by Andrey Semashev 04 Mar '14

04 Mar '14

Hi, I'm seeing test compilation errors saying that some headers are missing. For example: http://www.boost.org/development/tests/develop/developer/output/teeks99-01a… says that boost/smart_ptr/intrusive_ptr.hpp does not exist. There are other missing headers. The tester is teeks99-01a-win2008-64on64. Is this a known problem?

4 5

Boost.Convert. Take 2.
by Vladimir Batov 03 Mar '14

03 Mar '14

Another day I came across a topic called "String to T conversions - getting it right this time <http://groups.google.com/a/isocpp.org/group/std-proposals/t/a9905ba8e4f33f3e>" on the "ISO C++ Standard - Future Proposals <https://groups.google.com/a/isocpp.org/forum/#%21forum/std-proposals>" that got me interested/curious. Unfortunately, it seemed more of a discussion rather than a proposed/deployable solution to the string conversion issue. Then, I searched Boost archives to see if there was any development in that string-to-type conversion domain since my unsuccessful proposal about three years ago: From: Edward Diener <eldiener <at> tropicsoft.com> Subject: [Review] Boost.Convert, review manager analysis <http://news.gmane.org/find-root.php?message_id=iq12fm%24k6c%241%40dough.gma…> Newsgroups: gmane.comp.lib.boost.devel <http://news.gmane.org/gmane.comp.lib.boost.devel>, gmane.comp.lib.boost.user <http://news.gmane.org/gmane.comp.lib.boost.user> Date: 2011-05-06 15:01:06 GMT (2 years, 39 weeks, 6 days, 23 hours and 47 minutes ago) Unfortunately I was not able to find anything. Apologies if I missed something major/serious (I was not exactly closely monitoring the list). Is anyone aware of any work done in the area? If not, then I am thinking if we could revisit the issue the original (and failed) Boost.Convert tried to address. I am not sure about others but for me that quite essential and seemingly simple task is still quite important. I was watching the development of the lexical_cast but did not see it going beyond its original frugal design. So, maybe we might have another look at the code that Boost.Convert has become and that I've been using/working on?.. Convert V2... From past experience calling it Boost.Convert seems quite premature. :-) I only put Boost.Convert in the title as a reminder for those who participated in the original review. So, the code is at https://github.com/yet-another-user/boost.xtra. The docs are old (from the original proposal) so, if anyone interested, I'd suggest jumping right to the test/example code in libs/convert/test. Apologies for the inconvenience but for now I'll try to see if I should put any effort updating the docs for possible submission. The main difference from the original proposal is that the complicated blob was split in to two separate components -- Convert API facade and a converter. Here it seems very similar to (same as?) boost::lexical_cast which provides a uniform API facade which in turn deploys additional functionality (op<<, op>>). Similarly, Convert V2 requires a converter to be specified for conversion: boost::cstringstream_based_converter ccnv; // char converter boost::wstringstream_based_converter wcnv; // wchar_t converter Then, int a000 = convert<int>::from(not_int_str, -1, ccnv); int a001 = convert<int>::from(std_str, -1, ccnv); int a002 = convert<int>::from(c_str, -1, ccnv); int a003 = convert<int>::from(wstd_str, -1, wcnv); int a004 = convert<int>::from(wc_str, -1, wcnv); Now all the configuration (formatting, locales, etc.) is separate from the API facade and provided (or not) by the plugged in converter. The only available converter tringstream_based_converter allows something like: std::locale rus_locale (rus_locale_name); std::locale eng_locale (""); // Set locale, case, precision, ccnv(std::setprecision(4))(std::scientific)(std::nouppercase); string double_rus = convert<string>::from(double_v01, ccnv(rus_locale)).value(); string double_eng = convert<string>::from(double_v01, ccnv(eng_locale)).value(); Gosh, it's getting too long... cutting it short. The above is probably sufficient for those who participated in the original review. Those who did not might have a look at the (original and old) docs and the test/example code. V.

9 45

[assert] Assert library? - Was: [regression] Where's boost/assert.hpp ??
by Klaim - Joël Lamotte 01 Mar '14

01 Mar '14

On Sat, Feb 22, 2014 at 9:39 PM, Andrey Semashev <andrey.semashev(a)gmail.com>wrote: > It's been moved to a new Boost.Assert library (libs/assert submodule). Is there a discussion or documentation about what is this new library exactly? Is it just to isolate the assert.hpp header or are there other plans? (I'm secretly hoping that someone would propose an implementation of n3877[1] to boost, as I don't have the time to do it myself) [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3877.pdf

5 17

Review request for Boost.Align
by Glen Fernandes 28 Feb '14

28 Feb '14

Source: http://github.com/glenfe/align Documentation: http://glenfe.com/align/doc/ Motivation: Tiny library to be used for all common alignment related chores found in a few Boost libraries. (e.g. we have some in Boost.Smart_Ptr). Provides: 1. Function boost::align, a pointer alignment function, for implementations that do not yet provide std::align. (Uses std::align if available) 2. Functions boost::aligned_alloc and boost::aligned_free, for aligned allocation and deallocation. (Use platform specific functions, such _aligned_malloc or posix_memalign, or otherwise uses std::malloc with the above boost::align) 3. Class template boost::aligned_allocator as a replacement for std::allocator that respects over-aligned types. (Up to the extent the implementation supports over-alignment) Many thanks to Peter Dimov for his feedback on the design and implementation of this library. Notes: Small enough that it might satisfy the requirements for a fast-track review. Glen

9 24