- Boost - lists.boost.org

Boost.Uuid and header-only support
by James E. King, III 08 Nov '17

08 Nov '17

Hi folks, I have an open defect related to a random seed generator that's currently in boost::uuids::detail called seed_rng. The class does a fair bit more than it really needs to, and does not support Universal Windows Platform (UWP) store targets. It is otherwise quite similar to boost::random::random_device however it is a header-only implementation (in fact seed_rng has a comment about putting it into Boost.Random). I was planning on removing it and leaving randomness to Boost.Random because that's where the code really belongs, however this would introduce a new library dependency on Boost.Random for any code using boost::uuids::random_generator. So I'm curious on how important folks believe it is to maintain the header-only status of Boost.Uuid. Thanks, Jim

8 48

Preferred way to simulate system calls
by James E. King, III 06 Nov '17

06 Nov '17

I like to test every branch, and I have a class that calls open/read/close. It uses a hardcoded filename ("/dev/urandom"). It is a template in a detail namespace. What's the "boost way" when it comes to mocking these system calls? Should I make protected methods that normally call open/read/close, then subclass in a test and override them with different logic to force error paths? - Jim

3 2

[config] Rethinking feature macros?
by Peter Dimov 06 Nov '17

06 Nov '17

Now that there are standard feature-testing macros (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0096r5.html) that are being implemented by at least g++ and clang++, would it perhaps make sense for us to reevaluate our decision to provide negative macros in Boost.Config and start defining the standard feature macros instead on the compilers that don't support them? This would seem to require less maintenance, and the feature macro can be used without waiting for Boost.Config to add it. For a concrete example, let's take noexcept in function types. This is __cpp_noexcept_function_type, and is implemented by g++ 7, clang 4, clang 5 (in C++17 mode), and apparently in the latest VS2017 preview. noexcept function pointers break Boost.Bind, and to fix it, I need to add overloads for them, but only if they are implemented, otherwise the overloads would be an error. With the feature macro, I can just #ifdef __cpp_noexcept_function_type and it will immediately work on g++ and clang++ and all compilers that don't support noexcept function types will still work. Only msvc would need to be fixed in some way. With our traditional approach, I would need to request the addition of BOOST_NO_CXX17_NOEXCEPT_FUNCTION_TYPE, wait for it to be added and to be present on every compiler except the latest ones (which requires changes throughout Boost.Config), and only then be able to use #ifndef BOOST_NO_CXX17_NOEXCEPT_FUNCTION_TYPE. (Then wait for it to be merged to master before merging my changes to master.)

8 36

[optional] Regression in develop
by Andrzej Krzemienski 06 Nov '17

06 Nov '17

Hi Everyone, Over the weekend I added changes to Boost.Optional in develop which caused regression in Boost.Beast and maybe more libraries. I would like to ask for your input as to how to best approach this. The change was: for trivial `T` use a different specialization of `optional<T>` which is trivially-copyable. For this, I need the ability to declare defaulted functions, and to detect that a given type is trivial. Boost.TypeTraits do not have `is_trivial` trait, so I compose it form `has_trivial_move` and the like. But it seems there are compilers for which Boost.config and Boost.TypeTraits report support for deleted functions/triviality detection, but where this support is buggy. The following is a test case in type_traits by Vinnie Falco: https://github.com/boostorg/type_traits/pull/52/commits/9779157a787620d1633… In addition, the deadline for changes in release 1.66 is getting nigh. I can see a couple of ways to fix this: 1. Fix Boost.Config and/or Boost.TypeTraits so that they only report support for the features in question when it is supported without bugs. But I do not know if there is enough time for this given the deadline. 2. Disable my feature on the compilers with buggy support. But I would need a help from someone who knows all the compilers and their bugs in implementation of trivial type traits so that I can put the wight `#ifdef`s. 3. Just revert my changes to Optional, which is also an option, but would also be a loss. Any input from Boost experts would be appreciated. Regards, &rzej;

5 13

[msm] Unmerged changes in develop need review
by Peter Dimov 05 Nov '17

05 Nov '17

Boost.MSM has a number of long-unmerged changes in develop. If anyone who is familiar with MSM and cares about its state would like to review these changes and issue a recommendation on whether they, or which of them, need to be merged to master, now would be a good opportunity to do so.

1 0

[beast] Video Presentation: Designing an HTTP message container
by Vinnie Falco 05 Nov '17

05 Nov '17

Greetings! This is the video for my CppCon 2017 presentation. In this presentation I discuss designing a class for storing HTTP messages, defining some concepts along the way. The concepts are based on the ideas in Beast, but simplified for the presentation format. Anyone who is interested in learning some techniques, or getting a more advanced understanding of the Beast message container, may benefit from this video. Also, the video is entertaining on its own. Here it is: <https://www.youtube.com/watch?v=WsUnnYEKPnI> This page also contains the embedded video along with additional exposition not found in the talk: <http://www.boost.org/doc/libs/master/libs/beast/doc/html/beast/design_choic…> Thanks!

1 0

PGI
by Oliver Kowalke 05 Nov '17

05 Nov '17

Hi, does someone work on the boost-config for PGI? Running the unit-tests of boost.config fails but PGI 17.x should be C++11 compatible. Oliver

2 1

Mobile site
by Daniel James 04 Nov '17

04 Nov '17

Hi, I've been doing a little work on getting the website to work better on mobile phones. You can see it on the beta site: https://beta.boost.org There's still a lot to do, especially on the sidebar which is not really usable at the moment, so don't expect it to go live any time soon. Daniel

2 3

[parameter] RFE: perfect forwarding
by Cromwell Enage 02 Nov '17

02 Nov '17

Hi, everyone! I'm back from a long hiatus. Is anyone still interested in enhancing Boost.Parameter to handle perfect forwarding? If so, I have a patched version available at <http:/ github.com/CromwellEnage/boost-parameter-perfect_forwarding>. It includes existing header files and test source files that were modified, a few new header files and test programs, and corresponding changes to the .rst documentation files. Questions, concerns, and comments are welcome! Cromwell D. Enage

2 1

[poly_collection] Needs a 'develop' branch
by Edward Diener 02 Nov '17

02 Nov '17

The new library Boost poly_collection only has a 'master' branch. It needs to have a 'develop' branch also.

3 5