- Boost - lists.preview.boost.org

[phoenix] Test failures on clang
by Andrey Semashev 18 Apr '14

18 Apr '14

Hi, I'm seeing Boost.Log test failures on clang. The errors come from Boost.Phoenix/Boost.Proto: http://www.boost.org/development/tests/develop/developer/output/marshall-ma… It seems like actor assignment operator got broken recently.

2 1

Benchmarks comparing JSON libraries - including JSon Spirit
by Klaim - Joël Lamotte 17 Apr '14

17 Apr '14

http://blog.thousandeyes.com/efficiency-comparison-c-json-libraries/ I think this benchmark (with sources) might interest people who were recently planning to make an official Boost library for JSON parsing. In particular, this benchmark include JSon Spirit which is based on Boost Spirit. These benchmark might be useful for future tests.

4 5

Help with a shared_ptr problem on Android (ARM)
by Peter Dimov 17 Apr '14

17 Apr '14

https://svn.boost.org/trac/boost/ticket/9912 reports that spinlock_gcc_arm.hpp segfaults on a Nexus 7. Unfortunately, I know next to nothing about ARM or Android, so I wonder if someone can help with that.

3 4

Application : Question about Review/Review Manager
by Renato Forti 17 Apr '14

17 Apr '14

Hi All, The proposed Boost.Application is on review schedule. http://www.boost.org/community/review_schedule.html I have one question! How get a Review Manager? Anyone can help in this process? How this work? Thanks

2 1

[algorithm] Split that appends
by Sebastian Karlsson 17 Apr '14

17 Apr '14

First of all I think it's a bit unintuitive that boost::algorithm::split swaps with target, I would've assumed it appended. The fact that it in effect clears target makes it cumbersome to incrementally split into a destination, as you need a new temporary for every call to split, and then explicitly transfer everything over to your final destination. The docs do mention the behavior as a note ( which I presume is precisely because it's a bit unintuitive ). My question then naturally becomes why does split behave like this? As changing the behavior would be a breaking change, do you think it would be unreasonable to have a split_append? Kind regards, Sebastian Karlsson

5 5

[property_tree] xml_parser::read_xml() and write_xml() are limited to std::string keys
by Alexander Bogdashevsky 17 Apr '14

17 Apr '14

boost::property_tree::xml_parser and json_parser are hardcoded to work only with keys of std::string type. The following code will fail to compile: boost::property_tree::basic_ptree<boost::container::string, boost::container::string> pt; std::string filename("123.xml"); boost::property_tree:xml_parser::read_xml(filename, pt); I have prepared a patch that removes this limitation. Please consider pulling https://github.com/sanderbog/property_tree/commit/8af8b6bf3b65fa59792d849b5… Kind Regards, Alexander Bogdashevsky

1 0

[math] & [random] distribution object compatibility
by Thijs van den Berg 16 Apr '14

16 Apr '14

Boost [random] has probability distribution objects for drawing random samples of those distributions. Boost [math] also has probability distributions, those provide free functions for computing properties of the distributions, like mean, pdf etc. I like the free function design of math variant e.g. it uses pdf(distribution,x) and I was wondering why this hasn’t been adopt in C++11 for <random>? To me a free function syntax like random(distribution,engine) would make sense. It would align with the fact that C++11 has added begin(container) and end(container) free functions. I think it’s a bit inconvenient to have two libs that both contain probability distributions. Especially since I’m hoping that boost/math would some day en up in the standard? One way we could integrate the two libs is by adding a random(distribution,engine) free function to the math lib which would accept both distribution objects from the random lib and the math lib. This however could stimulate users in writing less C++11 portable code. My questions are: * Why wasn’t the free function syntax adopted in C++11? Perhaps because of performance options? * Is there an effort to integrate the distributions in math and random within boost? * Are there concrete plans to add elements of math to the C++ standard? We already have <random> now, I would love more.

3 5

clang++ isn't getting the BOOST_NO_CXX11_HDR_FUNCTIONAL flag that it needs
by Chris Cooper 16 Apr '14

16 Apr '14

Trying to build & run the regression tests for boost 1.55 on my Mac using the clang++ that comes with Xcode 5.1 ("Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)”), it can’t build config_test.cpp because BOOST_NO_CXX11_HDR_FUNCTIONAL isn’t set, and libs/config/test/boost_no_ccx_hdr_functional.ipp definitely doesn’t build (after renaming it to .cpp of course). If I set CXXFLAGS to "-std=c++11 -stdlib=libc++” everything is fine, but I also need a build of boost that _doesn’t_ use c++11, and it’s the non-c++-11 version that is failing. I can get around this by manually setting CXXFLAGS to “-DBOOST_NO_CXX11_HDR_FUNCTIONAL” but it seems like the correct way to do this is to add a test to boost/config/compiler/clang.hpp that tests … something… and then sets BOOST_NO_CXX11_HDR_FUNCTIONAL if appropriate. 1. Would you agree that’s the right place to set BOOST_NO_CXX11_HDR_FUNCTIONAL (when appropriate)? 2. Any suggestions on the correct test to determine whether BOOST_NO_CXX11_HDR_FUNCTIONAL is needed? It looks like the _has_feature() macro is the preferred method, but I can’t figure out which feature to check for … Thanks, Chris p.s. The text of the 3 errors (when trying to compile boost_no_cxx_hdr_functional) is exceedingly lengthy, but to summarize: usr/bin/../lib/c++/v1/__functional_base_03:962:22: error: no matching function for call to '__invoke' typedef decltype(__invoke(_VSTD::declval<_Fp>())) type; usr/bin/../lib/c++/v1/__config:496:32: note: expanded from macro 'decltype' #define decltype(x) __typeof__(x) usr/bin/../lib/c++/v1/__functional_base_03:1019:14: note: in instantiation of template class 'std::__1::__invoke_return<int &, false>' requested here typename __invoke_return<type&>::type ./boost_no_cxx_hdr_functional.ipp:22:4: note: in instantiation of template class 'std::__1::reference_wrapper<int>' requested here std::ref(i); usr/bin/../lib/c++/v1/__functional_base_03:962:22: error: no matching function for call to '__invoke' typedef decltype(__invoke(_VSTD::declval<_Fp>())) type; usr/bin/../lib/c++/v1/__config:496:32: note: expanded from macro 'decltype' #define decltype(x) __typeof__(x) usr/bin/../lib/c++/v1/__functional_base_03:1019:14: note: in instantiation of template class 'std::__1::__invoke_return<const int &, false>' requested here typename __invoke_return<type&>::type ./boost_no_cxx_hdr_functional.ipp:23:4: note: in instantiation of template class 'std::__1::reference_wrapper<const int>' requested here std::cref(i); ./boost_no_cxx_hdr_functional.ipp:36:9: error: no member named 'bind' in namespace 'std'; did you mean 'find'? std::bind(f, std::placeholders::_1, 0.0f);

3 2

[GIT] Access
by Artyom Beilis 16 Apr '14

16 Apr '14

I hadn't committed changes for a while. >From what I've read in the mailing list there was a move to GIT and svn was closed. However I can't find information on the GIT at the boost site. Are we still using SVN? Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/

3 2

Re: [boost] -serialization- segfault on startup
by Biddiscombe, John A. 16 Apr '14

16 Apr '14

Andrey Thanks for the info. I purged every stray lib I could find - double checked all ld_library_path entries and discovered there was a shared lib from a previous build on my path which was almost certainly the culprit in this case. However, now the filesystem error has gone and I'm left with a very similar one which previously was bothering me from boost.serialization. This one I can't make disappear by cleaning paths because there's nothing bad left that might be a problem. I tried this time with boost_1.54 just to see if anything changed. does this stack trace look familiar to anyone? thanks JB #0 0x00000080a0b272f4 in ._dl_fixup () from /lib64/ld64.so.1 #1 0x00000080a0b2fd78 in ._dl_runtime_resolve () from /lib64/ld64.so.1 #2 0x00000fffb689869c in ._ZN5boost13serialization9singletonINS_7archive6detail22archive_serializer_mapIN3hpx4util24portable_binary_oarchiveEEEE12get_instanceEv () at /gpfs/bbp.cscs.ch/home/biddisco/apps/gcc-4.8.2/boost_1_54_0/include/boost-1_54/boost/serialization/singleton.hpp:128 #3 0x00000fffb3a93008 in ._Z41__static_initialization_and_destruction_0ii () at /gpfs/bbp.cscs.ch/home/biddisco/apps/gcc-4.8.2/boost_1_54_0/include/boost-1_54/boost/serialization/singleton.hpp:149 #4 0x00000fffb3a93064 in ._GLOBAL__sub_I_portable_binary_oarchive.cpp () at /gpfs/bbp.cscs.ch/home/biddisco/src/hpx/src/util/portable_binary_oarchive.cpp:207 #5 0x00000fffb3a969f8 in .__do_global_ctors_aux () from /gpfs/bbp.cscs.ch/home/biddisco/bgas/gcc/build/hpx/lib/hpx/libhpx_serializationd.so.0 #6 0x00000fffb3a89ae4 in ._init () from /gpfs/bbp.cscs.ch/home/biddisco/bgas/gcc/build/hpx/lib/hpx/libhpx_serializationd.so.0 #7 0x00000080a0b27bf0 in ._dl_init_internal () from /lib64/ld64.so.1 #8 0x00000080a0b154dc in ._dl_start_user () from /lib64/ld64.so.1

1 0