July 2013 - Boost - lists.preview.boost.org

Re: [boost] [utility][thread] result_of - erroneous result type from a C++11 lambda
by Klaim - Joël Lamotte 04 Jul '13

04 Jul '13

On Tue, Apr 2, 2013 at 7:16 PM, Vicente J. Botet Escriba < vicente.botet(a)wanadoo.fr> wrote: > I've started to use C++11 lambda functions with Boost.Thread. > > The following works with clang-3.2 > > boost::future<int> f1 = boost::async( []() -> int {return 123;} ); > > > But it fails with gcc-4.6.2, 4.7.2 and 4.8.0 > > ../example/lambda_future.cpp:**25:91: erreur: conversion from > ‘boost::future<void>’ to non-scalar type ‘boost::future<int>’ requested > boost::future<int> f1 = boost::async( []() -> int {return 123;} ); > > The current implementation of boost::async uses boost::result_of to get > the result type of the callable parameter. > > Is this a know bug on boost::result_of or gcc compiler? > I'm seeing exactly the same behaviour in *VS2012 Update 2*. I'm using Boost 1.54.0 beta *r84748* To be more precise: 1) I first was just using boost::future and tried to use the new .then(), here is a full repro: #include <boost/thread/future.hpp> auto ft = boost::async( []{ return 42; } ).then( []( boost::future<int> r ){ return 666; } ); This fails because boost::async() returned a future<void> instead of a future<int>. I suspect the then() call to have the same problem. I can provide the full error log but I think it's not that useful. 2) Just to be sure I tried this full test: #include <boost/thread/future.hpp> int main() { auto ft = boost::async( []{ return 42; } ); // SUCCEED: static_assert( std::is_same< decltype(ft), boost::future<void> >::value, "WTF???" ); // FAILS: static_assert( std::is_same< decltype(ft), boost::future<int> >::value, "Not the expected type!" ); } Both asserts confirm that I don't get what I want. 3) I remembered that there were some issues from usage of boost::result_of in Boost.Log, so to clarify the situation I setup the following full test: #include <boost/utility/result_of.hpp> #include <type_traits> int top() { return 42; } struct K { int operator()(){ return 42; } typedef int value_type; }; auto F = []{ return 42; }; int main() { // A: ALL SUCCEED static_assert( std::is_same< decltype(K()()), int >::value, "Not the expected type!" ); static_assert( std::is_same< decltype(top()), int >::value, "Not the expected type!" ); static_assert( std::is_same< decltype(F()), int >::value, "Not the expected type!" ); // B: ALL SUCCEED static_assert( std::is_same< std::result_of<K()>::type, int >::value, "Not the expected type!" ); static_assert( std::is_same< std::result_of<decltype(top)>::type, int >::value, "Not the expected type!" ); static_assert( std::is_same< std::result_of<decltype(F)()>::type, int >::value, "Not the expected type!" ); // C: ALL SUCCEED std::result_of<K()>::type a = K()(); std::result_of<decltype(top)>::type b = top(); std::result_of<decltype(F)()>::type c = F(); // D: ALL FAILS static_assert( std::is_same< boost::result_of<K()>::type, int >::value, "Not the expected type!" ); static_assert( std::is_same< boost::result_of<decltype(top)>::type, int >::value, "Not the expected type!" ); static_assert( std::is_same< boost::result_of<decltype(F)()>::type, int >::value, "Not the expected type!" ); // E: ALL FAILS boost::result_of<K()>::type d = K()(); // error C2182: 'd' : illegal use of type 'void' boost::result_of<decltype(top)>::type e = top(); // error C2182: 'e' : illegal use of type 'void' boost::result_of<decltype(F)()>::type f = F(); // error C2182: 'f' : illegal use of type 'void' } This shows clearly that: 1. boost::result_of don't behave like std::result_of on this platform (and from previous discussions, on other platforms too). 2. both std::result_of and decltype() provide the result I expect from reading documentations about these. So far I'm assuming that the problem really is from boost::result_of, but I might be wrong because the differences with std::result_of are not clear to me. ---- Unfortunately this makes future.then() unusable if we expect return types. I don't know if it impacts other libraries (I suspect Boost.Log). Should I report a bug or is it known, already fixed or a misuse? Joel Lamotte

5 12

[result_of] Documentation update for ticket 7753
by Nathan Crookston 03 Jul '13

03 Jul '13

Hi Daniel & all, I'm updating the patch for ticket 7753 ( https://svn.boost.org/trac/boost/ticket/7753) I've made the requested changes to the patch, but I had a question on how to best explain which macro to define if, for example, you want result_of to work with C++11 lambdas. In the past, users with a pre-N3276 decltype have been advised to just #define BOOST_RESULT_OF_USE_DECLTYPE, with the explanation that "it's probably just going to work." While that advice is true, there are cases where this doesn't work; hence the addition of BOOST_RESULT_OF_USE_TR1_WITH_DECLTYPE_FALLBACK. To explain why you'd define the FALLBACK macro over the USE_DECLTYPE macro, I'm thinking of including a paragraph like the following. "The question naturally arises on why have both BOOST_RESULT_OF_USE_DECLTYPE and BOOST_RESULT_OF_USE_TR1_WITH_DECLTYPE_FALLBACK. In many situations, BOOST_RESULT_OF_USE_DECLTYPE will work well, even with pre-N3276 decltype. However, there are cases where a post-N3276 decltype is required to correctly deduce the return type of a functor. If a translation unit includes a functor whose return type is only deducible with TR1 or a post-N3276 decltype, using result_of with, e.g. a C++11 lambda function, will fail without BOOST_RESULT_OF_USE_TR1_WITH_DECLTYPE_FALLBACK. If the macro BOOST_NO_CXX11_DECLTYPE_N3276 is defined and BOOST_NO_CXX11_DECLTYPE is not defined when including result_of.hpp, defining BOOST_RESULT_OF_USE_TR1_WITH_DECLTYPE_FALLBACK is the safest option that will allow you to deduce C++11 lambda return types." My question is, am I over explaining it? Of course, I'd rather have BOOST_RESULT_OF_USE_TR1_WITH_DECLTYPE_FALLBACK defined automatically for compilers like VC10, g++4.5, etc., and include text like the following: "If you rely on the result of calling a nullary functor to be void, regardless of the actual return type, or if your code is not written to handle cases other than BOOST_RESULT_OF_USE_TR1 and BOOST_RESULT_OF_USE_DECLTYPE, you may wish to explicitly define one of those symbols prior to including result_of." Either way, comments welcome. Thanks, Nate

3 4

Want to contribute, need advice.
by Manmohit Rekhi 03 Jul '13

03 Jul '13

Hello, Am Manmohit Rekhi, a 2nd year computer engineering student at Nirma university, India. I have some programming experience in c and c++. Am interested in contributing to Boost, and would like to ask a few questions, to help me get started. I would be really grateful is, i could get the following questions answered. 1) Do i need to be familiar with the code of the standard c++ libraries, and if so, where do i start? 2) What other per-requisites are there? 3) Where do i start reading the boost libraries(i mean which file to read first)? Thanking You, Manmohit Rekhi

2 1

[Serialization] Constructor for polymorphic archives
by Bjorn Reese 03 Jul '13

03 Jul '13

I have a set of my own Boost.Serialization archives (e.g. [1]) that I wish to write polymorphic variants of. I have tried to follow the blueprint from polymorphic_text_iarchive, which inherits from polymorphic_iarchive_route. The problem is that the constructor of my archives takes iterators (begin and end) as arguments, but the polymorphic_iarchive_route constructor expects a std::stream argument. Is there any workaround for this? [1] http://sourceforge.net/p/protoc/code/ci/master/tree/include/protoc/transenc…

3 4

[Operators] Update, const-correctness and operator chaining
by Andrew Ho 02 Jul '13

02 Jul '13

Hi, I was doing some testing with Daniel Frey/Marc Glisse's proposed 4- overload set for binary operators. For reference, here's the overload set applied to commutative addition: friend T operator +( const T& lhs, const T& rhs) { T nrv(lhs); nrv += rhs; return nrv; } friend T operator +(T&& lhs, const T& rhs) { return std::move(lhs += rhs); } friend T operator +(const T& lhs, T&& rhs) { T nrv(lhs); nrv += boost::move(rhs); return nrv; } friend T operator +(T&& lhs, T&& rhs) { return boost::move(lhs += boost::move(rhs)); } This allows this to be done: val1 + val2 = val3; changing the return type to const T would allow the compiler to catch this, but now doing val1 + val2 + val3 must always use copy semantics instead of move semantics. I can't think of a way which would fix this issue without breaking the use of move semantics. How should we proceed with this? It's obviously bad usage, but the compiler should be able to catch this since it's easy to mistype + as =. Interestingly enough, doing testing with std::string shows the same "problem": std::string str1("hello"), str2(" "), str3("world"); str1 + str2 = str3; I tested this issue with std::string and found it in vs2012, gcc 4.3.2, and mingw/gcc 4.8.0. I don't have access to a compiler which pre-dates C++0x/C++11 so I don't know if this issue has always been present. Compiling with gcc 4.8.0 with - std=c++03 still has the issue.

3 3

Any interest in bitstream class?
by Paul Long 02 Jul '13

02 Jul '13

Same semantics as, e.g., stringstream, but it operates on binary data. I already have the analogues to istringstream/stringbuf (you can take a look at ibitstream/bitbuf at https://github.com/dplong/bstream) There are some interesting features, but I won't go into them here. If there is interest, I would implement obitstream and bitstream and possibly support Boost::dynamic_bitset. The rationale is _succinct_ expression of predictive parsing of binary data. I've used ibitstream in production code for decoding RTP headers and frames of various video encodings. Below is a simple function that decodes an RTP header using ibitstream; I also have a GitHub repo that contains more complex code for high-level parsing of H.264 frames at https://github.com/dplong/rtspudph264 struct RtpHeader { bool padding, marker; bitset<7> payloadType; WORD sequenceNumber; DWORD timestamp, ssrcIdentifier; vector<DWORD> csrcIdentifier; struct { bool present; WORD identifier; vector<BYTE> contents; } extension; }; bool ParseRtpHeader(const BYTE *buffer, RtpHeader &rtp) { ibitstream bin(buffer); static const bitset<2> version(0x2); bitset<4> csrcCount; WORD extensionLength; bin >> version >> rtp.padding >> rtp.extension.present >> csrcCount >> rtp.marker >> rtp.payloadType >> rtp.sequenceNumber >> rtp.timestamp >> rtp.ssrcIdentifier >> setrepeat(csrcCount.to_ulong()) >> rtp.csrcIdentifier; if (rtp.extension.present) { bin >> rtp.extension.identifier >> extensionLength >> setrepeat(extensionLength * sizeof(DWORD)) >> rtp.extension.contents; } return bin.good(); }

10 47

Static initialization of boost shared objects question
by Juan Carlos Franzoy 02 Jul '13

02 Jul '13

Hello. Thanks for reading my question. I fell into a deadlock in static initialization of boost shared objects. The deadlock occurs in a reentrant call to a function which contains a definition of a static variable. Apparenlty gcc protects the initialization of such variables with a condition variable. Looking at the c++ code nothing at all make anybody suspect about reentrancy. My "interpretation of the fact" may be titled 'something in gcc, ld, ld.so, c++language made the call to be reentrant' - There is a function boost::system::generic_category() that has a static variable V - V type is boost::system::annonymous-namespace::generic_error_category - boost::system::annonymous-namespace::generic_error_category is subclass of boost::system::error_category. - boost::system::annonymous-namespace::generic_error_category has no declared/defined constructor as well as all its superclasses - The compilation process generate the constructor boost::system::error_category::error_category() as a weak symbol inside every shared object that uses it. - There is a static variable boost::system::posix_category in one of the shared objects that is initialized calling boost::system::generic_category(). - when the static initialization of a shared object boost::system::posix_category get initialized - which calls boost::system::generic_category() - Inside boost::system::generic_category() starts the initialization of V which calls boost::system::error_category::error_category() - It may happend that the runtime calls an instance of boost::system::error_category::error_category() that resides in a shared object that is still not loaded - So that .so get loaded and it is called its own static initialization - which can call boost::system::generic_category() - BOOM I would love if you can confirm of refute my humble "interpretation". Details follows ------------------- boost version: 1-52-0 Operating system: uname -a SunOS bcpp-solaris10 5.10 Generic_147441-25 i86pc i386 i86pc $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/export/home/local/gcc-4.6.2/libexec/gcc/i386-pc-solaris2.10/4.6.2/lto-wrapper Target: i386-pc-solaris2.10 Configured with: ../src/gcc-4.6.2/configure --prefix=/export/home/local/gcc-4.6.2 --with-gmp=/export/home/local/gcc-4.6.2/gmp-4.3.2 --with-mpfr=/export/home/local/gcc-4.6.2/mpfr-3.0.0 --with-mpc=/export/home/local/gcc-4.6.2/mpc-0.8.2 --with-libelf=/export/home/local/gcc-4.6.2/libelf-0.8.12 --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --enable-languages=c,c++ --with-as=/usr/local/bin/as --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-plugin --enable-multilib --enable-version-specific-runtime-libs --enable-bootstrap --enable-ssp --enable-libssp --with-included-gettext --enable-lto --host=i386-pc-solaris2.10 --build=i386-pc-solaris2.10 Thread model: posix gcc version 4.6.2 (GCC) Callstack backtrace (lines begining with = are my comments): = = deadlock here: the threads is waiting itself = #0 0xfd459019 in __lwp_park () from /lib/libc.so.1 #1 0xfd45365e in cond_sleep_queue () from /lib/libc.so.1 #2 0xfd453817 in cond_wait_queue () from /lib/libc.so.1 #3 0xfd453b94 in cond_wait_common () from /lib/libc.so.1 #4 0xfd453d02 in _cond_wait () from /lib/libc.so.1 #5 0xfd453d2d in cond_wait () from /lib/libc.so.1 #6 0xfd453d66 in pthread_cond_wait () from /lib/libc.so.1 #7 0xfd632898 in __gthread_cond_wait (g=0xfd822ea8) at ...build-gcc/out/i386-pc-solaris2.10/libstdc++-v3/include/i386-pc-solaris2.10/bits/gthr-default.h:846 #8 __gthread_cond_wait_recursive (g=0xfd822ea8) at ...work/build-gcc/out/i386-pc-solaris2.10/libstdc++-v3/include/i386-pc-solaris2.10/bits/gthr-default.h:860 #9 __gnu_cxx::__cond::wait_recursive (g=0xfd822ea8) at ...build-gcc/out/i386-pc-solaris2.10/libstdc++-v3/include/ext/concurrence.h:377 #10 __cxa_guard_acquire (g=0xfd822ea8) at .../src/gcc-4.6.2/libstdc++-v3/libsupc++/guard.cc:289 = = Reentrant call to boost::system::generic_category() = #11 0xfd812313 in boost::system::generic_category () at libs/system/src/error_code.cpp:425 #12 0xfe85cd38 in __static_initialization_and_destruction_0(__initialize_p=1, __priority=65535) at ./boost/system/error_code.hpp:214 #13 0xfe85d05f in _GLOBAL__sub_I_instantiate_re2c_lexer_str.cpp () at libs/wave/src/instantiate_re2c_lexer_str.cpp:56 = = static initization of boost.wave library = #14 0xfe8868fd in __do_global_ctors_aux () from ...boost/lib/libboost_wave-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #15 0xfe88692a in _init () from ...boost/lib/libboost_wave-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #16 0xfefce37e in call_init () from /usr/lib/ld.so.1 #17 0xfefce1cf in is_dep_init () from /usr/lib/ld.so.1 #18 0xfefdaa4b in elf_bndr () from /usr/lib/ld.so.1 #19 0xfefc2ab4 in elf_rtbndr () from /usr/lib/ld.so.1 #20 0xfee60688 in ?? () #21 0xfee0c8f6 in boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_alloc_>() at ./boost/exception/detail/exception_ptr.hpp:119 #22 0xfee0c0d2 in __static_initialization_and_destruction_0(__initialize_p=1, __priority=65535) at ./boost/exception/detail/exception_ptr.hpp:138 #23 0xfee0c271 in _GLOBAL__sub_I_future.cpp () at libs/thread/src/future.cpp:60 = = static initization of boost.thread library = #24 0xfee0d98d in __do_global_ctors_aux () from ...boost/lib/libboost_thread-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #25 0xfee0d9ba in _init () from ...boost/lib/libboost_thread-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #26 0xfefce37e in call_init () from /usr/lib/ld.so.1 #27 0xfefce1cf in is_dep_init () from /usr/lib/ld.so.1 #28 0xfefdaa4b in elf_bndr () from /usr/lib/ld.so.1 #29 0xfefc2ab4 in elf_rtbndr () from /usr/lib/ld.so.1 #30 0xfdce0688 in ?? () = = First calll to boost::system::generic_category() = #31 0xfd81232a in boost::system::generic_category () at libs/system/src/error_code.cpp:425 #32 0xfd812386 in __static_initialization_and_destruction_0(__initialize_p=1, __priority=65535) at ./boost/system/error_code.hpp:214 #33 0xfd8123ed in _GLOBAL__sub_I_error_code.cpp () at libs/system/src/error_code.cpp:430 = = static initialization of boost.system = #34 0xfd8126ed in __do_global_ctors_aux () from ...boost/lib/libboost_system-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #35 0xfd81271a in _init () from ...boost/lib/libboost_system-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #36 0xfefce37e in call_init () from /usr/lib/ld.so.1 #37 0xfefcd7d5 in setup () from /usr/lib/ld.so.1 #38 0xfefdba3e in _setup () from /usr/lib/ld.so.1 #39 0xfefc299c in _rt_boot () from /usr/lib/ld.so.1 #40 0x08047540 in ?? () #41 0x08047670 in ?? () More thanks for reading all.

3 4

zlib not building (fedora x86_64)
by Neal Becker 02 Jul '13

02 Jul '13

I noticed zlib are not being built. I don't know why. rpm -qa zlib* zlib-1.2.7-9.fc18.i686 zlib-1.2.7-9.fc18.x86_64 zlib-devel-1.2.7-9.fc18.x86_64 bjam cxxflags=-march=native -sHAVE_ICU=1 -sEXPAT_INCLUDE=/usr - sEXPAT_LIBPATH=/usr/lib64 --layout=tagged threading=single,multi link=shared stage warning: No toolsets are configured. warning: Configuring default toolset "gcc". warning: If the default is wrong, your build may not work correctly. warning: Use the "toolset=xxxxx" option to override our guess. warning: For more configuration options, please consult warning: http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html Performing configuration checks - 32-bit : no - 64-bit : yes - arm : no - mips1 : no - power : no - sparc : no - x86 : yes error: No best alternative for libs/coroutine/build/allocator_sources next alternative: required properties: <link>static <target-os>windows <threading>multi not matched next alternative: required properties: <link>static <segmented-stacks>on <threading>multi not matched next alternative: required properties: <link>static <threading>multi not matched - has_icu builds : yes warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - zlib : no - iconv (libc) : yes - icu : yes - compiler-supports-ssse3 : yes - compiler-supports-avx2 : yes - gcc visibility : yes - long double support : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. error: No best alternative for libs/coroutine/build/allocator_sources next alternative: required properties: <link>static <target-os>windows <threading>multi not matched next alternative: required properties: <link>static <segmented-stacks>on <threading>multi not matched next alternative: required properties: <link>static <threading>multi not matched - zlib : no (cached) Component configuration: - atomic : building - chrono : building - context : building - coroutine : building - date_time : building - exception : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - log : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - signals : building - system : building - test : building - thread : building - timer : building - wave : building

1 0

boost 1.54.0 support for VS2013
by Charles_J_Wilson＠Dell.com 01 Jul '13

01 Jul '13

Has visualc.hpp been updated to support VC++12? (this was released in Visual Studio 2013 preview). I get the following issue with 1.54.0 beta built with VC++11 when compiling using VC++12: Error 1 error C2039: 'assert_not_arg' : is not a member of 'boost::mpl' (..\..\..\Logging\source\Core.cpp) C:\Users\Charles_J_Wilson\Documents\Projects\external\open_source\boost\1.54.0\boost_1_54_0\boost\iterator\detail\facade_iterator_category.hpp 166 Which is: # if !BOOST_WORKAROUND(BOOST_MSVC, <= 1300) BOOST_MPL_ASSERT_NOT((is_iterator_category<Traversal>)); # endif The beta doesn't recognize the compiler version and suggests running the config tests. Where are the instructions for that? Charles Wilson Principal Software Development Engineer Dell | Enterprise Solutions Group

2 1