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

[uuid] sequential_generator / comb_generator / utc_generator / timestamp_generator
by Adam Walling 06 Mar '14

06 Mar '14

For personal use, I've created a few generators that create sequential and time-based uuids. However there does not seem to be a single standard for these kinds of algorithms. While tidying up this code, I've run into some obstacles with generalization of the logic. Although some applications like SQL Server will use GUIDs and lexicographically compare based on the least significant bytes of Data4 for boost::uuids' purposes we can simply assume a block of 16 bytes. The generic approach is to combine (basic_comb_generator) a number of bytes from a sequential source, filling the rest of the bytes with random data. What concerns me is the choice of source and the number of bytes to use. And additionally the value which specifies the variant / version. The usual choices seem to be 8 or 6 bytes. The source is also usually UTC Unix time. However the original uuid version used nanosecond intervals and the MAC address. Am I worrying too much about extensibility? As it is now my basic_comb_generator has a template param for a source, a number of bytes of the source to use, and a UniformRandomNumberGenerator to fill the rest. Since resolution may be a second if using Unix time they may not be consistently sequential but generally so, hence my hesitation to name the generator typedef as sequential. Of course it is possible to use even higher resolution. I suppose I am gauging interest in this feature, as well as asking if there are any thoughts or suggestions on how others would likely use this, and alternative or standard algorithms defined. Once I have some feedback I intend to complete the code and bounce it back on here for any further comments before lobbying to include anything within the library. It seems like commonly needed functionality at least! Nilsson article here for SQL Server: http://www.informit.com/articles/article.aspx?p=25862&seqNum=7 CouchDB's uuid generation algorithms: https://wiki.apache.org/couchdb/HttpGetUuids

2 1

[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

[range][documentation] - best practice for generating documentation?
by Neil Groves 05 Mar '14

05 Mar '14

Hi, I'm currently the suitably ashamed owner of numerous documentation trac issues for Boost.Range. I would like to address these issues but I'm unclear about what our strategy is for generating documentation since our move to modular Boost. I anticipate that if I continue to commit the generated html as I had done previously that I will be in for a "world of pain" when it comes to merge to master. I've searched and found several pages about document best-practice but the pages contain references to the subversion repository which leads me to believe that this must be out-of-date. I'd like some advice to ensure that my commits are aligned with what is wanted. If there is a temporary workflow I can use that will not end in a merge disaster then I'd like to put small documentation fixes in quickly before major re-factoring of the documentation generation process. I apologise in advance if my search skills have been deficient. Sending a link accompanied with abuse is entirely acceptable! Thanks, Neil Groves

2 3

[offtopic] Wonders of C++ syntax
by Andrey Semashev 05 Mar '14

05 Mar '14

Maybe this experience will be interesting to someone... I'm currently trying to write a simple parser for function signatures for Boost.Log and collecting different curious use cases. The parser is supposed to extract the function name from the compiler-generated string with the signature (i.e. BOOST_CURRENT_FUNCTION). Now the interesting case I've stumbled upon is a conversion operator to a function pointer: namespace namespc { struct my_class2 { typedef char (*pfunc_t)(double); operator pfunc_t () const { std::cout << BOOST_CURRENT_FUNCTION << std::endl; return 0; } }; } I first tried to imagine how this could be written without the typedef, but my brain broke soon enough. Then I decided to ask the compiler, and naturally different compilers gave different answers. GCC nicely sidestepped the problem altogether: namespc::my_class2::operator pfunc_t() const MSVC was more creative: __cdecl namespc::my_class2::operator char (__cdecl *)(double)(__cdecl *(void) const)(double) Frankly, my brain can't parse this one either and it looks incorrect to me since the function pointer type is duplicated. So it seems, there's no syntax for expressing the operator without a typedef, is that right? In that case, I wonder what to do with MSVC output...

2 2

changelog for 1.56
by Oliver Kowalke 05 Mar '14

05 Mar '14

I tried to add comments to the change log of 1.56 - but I've no permission to push the commit. is feed/history/boost_1_56_0.qbk the correct place and can I get permission to push commits?

2 1

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

Getting started with Boost( GSOC)
by M. Lalit 05 Mar '14

05 Mar '14

Hi Guys, I'm new to Open-Source Development.I want to contribute to Boost this year through GSOC-2014.I looked at the suggested projects this year at https://svn.boost.org/trac/boost/wiki/SoC2014 and liked Boost.Document Project and therefore I would like to work on it for this years GSOC.Please help me guys on how to get started for developing that project.I mean basically what codebase to understand etc.

2 5

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

Re: [boost] Review request for Boost.Align
by Glen Fernandes 05 Mar '14

05 Mar '14

On 2014-02-22, Ron Garcia wrote: > Hello, > > I have recieved your request and will add this library to the review schedule. > > Best, > Ron Description updated below. Code and documentation also updated. Code: http://github.com/glenfe/align/ Docs: http://glenfe.com/align/doc/ Description: This library provides function boost::align() for implementations which do not have the C++11 standard library std::align() function available. It provides allocation functions boost::aligned_alloc() and boost::aligned_free() as their functionality is not yet available in the C++ standard library. They use platform specific functions, such as posix_memalign(), aligned_malloc(), memalign(), if available, or use standard library functions in conjunction with boost::align(). It provides C++ allocators, class templates boost::aligned_allocator and boost::aligned_allocator_adaptor, which respect alignment. - The first is a replacement for the standard default allocator and uses boost::aligned_alloc() and boost::aligned_free(). - The second turns an existing allocator into one that supports alignment by using the allocator in conjunction with boost::align. It supports all C++03 and C++11 allocators, including C++11 allocators whose 'pointer' type is a smart pointer, and C++11 minimal allocators. It also provides function boost::is_aligned() to test the alignment of a pointer. -- end Glen

1 0

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