August 2018 - Boost - lists.preview.boost.org

Increasing BOOST_PP_VARIADICS_SIZE
by Damien Buhl 20 Aug '18

20 Aug '18

Dear Edward, In comparison to BOOST_PP_SEQ, BOOST_PP_VARIADICS is limited to 64 elements while BOOST_PP_SEQ is limited 255. Is there a reason for the choice of 64 or could I patch BOOST_PP_VARIADICS to go as BOOST_PP_SEQ to a limit of 255 ? Or asked differently do you think there are in newer compilers/standards a way to have an unbounded BOOST_PP_VARIADICS implementation nowadays ? Warm Regards, -- Damien Buhl Software Developer +33 6 77 43 10 05

2 2

ABI issues with -std
by Peter Dimov 20 Aug '18

20 Aug '18

At some point, we'll need to acknowledge the problem which results from building Boost with one -std and user code with another, and deal with it somehow, if just by documenting. Most of our libraries don't suffer from it at the moment but Boost.System does, because of my changes; its ABI changes between 03/11/14. So I'm going to take the initial hit. :-) POSIX platforms have long been able to ignore ABI issues so we don't mangle the library names there at all, but now whether one builds Boost for C++03, C++11 or C++14 matters, and there's nothing to prevent linking C++xx to C++yy. Even with --layout=versioned, the cxxstd level is not encoded. The fact that the default C++ standard differs between g++ and clang++ doesn't help; when following the instructions of doing "b2 install", with g++6 and above you get C++14, but with g++5 or clang++ you get C++03. The latter is very rarely what one wants today.

7 26

Formal review request: Synapse
by Emil Dotchevski 16 Aug '18

16 Aug '18

Hello, I'm requesting a formal review for Synapse, a non-intrusive signal programming library. Synapse is a non-intrusive C++ signal programming library. It is able to register connections and emit signals from any C or C++ object of any type whatsoever. If two contexts share access to a C or C++ object, they can use that object as a randezvouz point of sorts, and communicate with each other through Synapse signals. A system of meta signals provides interoperability with other signal programming libraries and callback APIs. In particular Synapse can be used to safely register C++ function objects, including lambda functions, with any C-style callback API that is designed to work only with C function pointers. In a multi-thread environment signals can be emitted asynchronously and scheduled for synchronous execution when requested in other threads. There have been numerous improvements since the first review, including the the ability to create persistent connections which don't require the user to explicitly keep them alive. See https://zajo.github.io/boost-synapse/. Thanks, Emil

2 1

Strange libstdc++ versions in travis-ci testers
by Andrzej Krzemienski 15 Aug '18

15 Aug '18

Hi Everyone, Maybe someone could help me understand the configuration on the travis-ci testers. Whenever I push a new commit I get a number of failures from travis-ci about missing std::is_trivially_default_constructible from the standard library; like here: https://travis-ci.org/boostorg/optional/builds/397519342?utm_source=email&u… Some tests with Boost.Predef indicate that they are clang compiler 3.X, and clang 5 with libstdc++ of strange version nubers: macro BOOST_LIB_STD_GNU gives values 450400026 and 460700026, which would correspond to releases 2015-04-26 and 2016-07-26, but when I look at the release notes for GCC there are no releases mentioned of these dates: https://gcc.gnu.org/news.html Maybe someone knows what versions of libstdc++ these are? Or maybe I am missing something obvious? Regards, &rzej;

5 12

numeric directory/namespace
by Robert Ramey 14 Aug '18

14 Aug '18

I'm preparing to make adjustments to safe_numerics directory and namespace in preparation to incorporating safe_numerics into the official boost distributions. I have a couple of decisions to make that someone/everyone will want to weigh in on. There is already a directory boost_root/libs/numeric which seems to be an "umbrella" for libraries dealing with numerics. It includes conversion, interval, odeint and ublas. There is an index.html in there also. But instead of referring to the above libraries, it points to the ublas documentation. So it's sort of tempting the place safe numerics in libs as a sub directory. But I really have strong reservations about the whole concept of have this "umbrella" directory in the first place. Personally I'd just prefer to use boost_root/libs/safe_numerics. I don't think the extra structure adds anything and makes it harder to implement tools which scan the directories. It would also mean that I should ? use #include <boost/numeric/safe_numeric/ ....> and I'm not sure want to do that. Also I expect I'll want to sync the namespace boost::numeric::safe_numeric:: ... with the file system. It just seems more complex and flexible than it has to be. I see the future of boost as diminishing coupling between libraries and I see the current setup as not helping with this. Please don't wait to answer until I've made the changes. Robert Ramey

3 2

[container] [flat_map] Error with heterogeneous comparator and std::string_view
by Viktor Sehr 13 Aug '18

13 Aug '18

On MSVC (latest) the following code yields a compile error with flat_map, but not with std::map. I do not have the knowledge of std::less<> to resolve what causes the error. auto fm = boost::container::flat_map<std::string, int, std::less<> >{}; auto m = std::map<std::string, int, std::less<> >{}; auto k = std::string_view{ "my_key" }; auto x = m.find(k); // Compiles auto y = fm.find(k); // Does NOT compile Error message: 1>boost\container\flat_map.hpp(1314): error C2664: 'boost::container::vec_iterator<boost::container::dtl::pair<Key,T> *,true> boost::container::dtl::flat_tree<boost::container::dtl::pair<Key,T>,boost::container::dtl::select1st<Key>,Compare,boost::container::new_allocator<T2>>::find(const std::basic_string<char,std::char_traits<char>,std::allocator<char>> &) const': cannot convert argument 1 from 'const std::string_view' to 'const std::basic_string<char,std::char_traits<char>,std::allocator<char>> &' 1> with 1> [ 1> Key=std::string, 1> T=int, 1> Compare=std::less<void>, 1> T2=boost::container::dtl::pair<std::string,int> 1> ] 1> boost\container\flat_map.hpp(1314): note: Reason: cannot convert from 'const std::string_view' to 'const std::basic_string<char,std::char_traits<char>,std::allocator<char>>' 1> boost\container\flat_map.hpp(1314): note: No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called Best regards /Viktor

4 7

Library Federation
by Robert Ramey 12 Aug '18

12 Aug '18

I'm now taking steps to get safe numerics integrated into the boost distribution. It's reminded me of a running complaint I have about using boost. a) When I use anything boost, I'm required to do two things: i) run b2 headers to create a forwarding header in the boost directory ii) include via command line or INCLUDE variable to boost root. b) If I want to use safe_numerics before it is included in the boost distribution, I have to place safe_numerics into it's expected destination in the boost hierarchy and run b2 headers AGAIN to make things match up. This is even more problematic in that b2 headers is not invoked "automagically" in such a way that people don't know it's there. To me, this just makes it harder to use / test any new library with boost without dragging in access to a bunch of stuff I may not want. It inhibits those without beam foo from running the tests etc. This is why I did things the way I did. Now I'm getting ready to add it to the boost distribution, I'll change this to do it the "boost way". Not so much because I think it's better but in this case, consistency is better than variety. But I'm still unsatisfied with the situation. It's part of the reason that boost is avoided when possible by many people. Isn't there a better way? I think there might be. Rather than sprinkling a bunch of forwarding headers around my file system - which are "sticky" and need to be updated from time to time, how about depending on the "INCLUDE" environmental variables available in gcc and msvc and clang. Using "some method", I would be able generate this variable via some sort of batch script - not too tough. And work as I do now. But a) the script would be re-run when ever I changed projects so that it "stuck" in my file system. b) It could be smarter - include only the boost include directories I'm actually using - thus avoiding accidently including surprising stuff. c) We have tools which figure out boost dependencies automatically so I don't think it would be a big stretch to do this automagically. d) If my project is "larger" and includes a bunch of stuff from other libraries, I could add these in as well. This would give my the concept of "library federation" where my app is linked to some list defined as part of the project. I'm sure this concept also sort of exists. e) my pet request would be that I could say: tool application.cpp ... >include environment output to generate the env output for all the target apps. Of course one could you * wild cards as well. This would let me create one set on includes for building/running my test suite and a different one for examples and a different one for my "real" application. I'll stop there so as to leave opportunity for discussion. Robert Ramey

3 7

Please merge into boostorg superproject
by James E. King III 11 Aug '18

11 Aug '18

Please merge into boost superproject - these have passed CI and have been reviewed: https://github.com/boostorg/boost/pull/186 https://github.com/boostorg/boost/pull/181 Please decide what to do with: https://github.com/boostorg/boost/pull/39 (I can't tell if this is defunct?) https://github.com/boostorg/boost/pull/184 (do we want this in the superproject, or a submodule called boostorg/docker, or not at all?) Thanks, Jim

1 0

iostreams in 1.68.0
by James E. King III 11 Aug '18

11 Aug '18

Hi folks, just a note that none of the changes since 1.67.0 got into 1.68.0 master. They were on develop and never merged. I just merged them for 1.69.0. - Jim

1 0

[release] 1.69.0 open for merging
by Marshall Clow 10 Aug '18

10 Aug '18

The master branch is open for merging all stable changes from develop, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging does not require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: https://github.com/boostorg/boost/wiki/Release-Schedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Boost Release Team

2 1