- Boost - lists.preview.boost.org

[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

Boost.odeint project for GSoC 2014
by Camille GILLOT 04 Mar '14

04 Mar '14

Hello, I am Camille Gillot. I am a student in French Ecole d'ingenieurs Ecole Polytechnique. I have been programming in C++ for a couple years now, and I would like to take part in boost development through GSoC this summer. I have taken a deep look on the GSoC proposals on boost trac, and I am very interested in working on the boost.odeint or the funtional/'invoke' project. May I have deeper informations on the expected work ? It is the first time I applied to a GSoC project and I worked on boost development, so I need some help about it. Regards, Camille Gillot

2 1