November 2017 - Boost - lists.preview.boost.org

Seeking endorsement for the reflection library (PFR)
by Antony Polukhin 10 Nov '17

10 Nov '17

Hello, PFR is a C++14 library that provides tuple-like methods for aggregate initializables. Library has a set of predefined operators and useful functions for everyday use. Works with user-defined types without any macro or boilerplate code. Library: https://github.com/apolukhin/magic_get Docs: http://apolukhin.github.io/magic_get/ Boost Library Incubator: http://blincubator.com/bi_library/pfr-pod-flat-reflection/?gform_post_id=16… Seeking for some endorsement, as per http://www.boost.org/development/submissions.html Library changes since last mail: * Now works on latest MSVC in C++17 mode * C++14 limitations in reflection were significantly relaxed * Removed UB (no more reinterpret casting of unrelated types!) * Thaler Benedek was approved as a review manager for the library. Boost libraries that may benefit from PFR: * Convert - for out-of-the-box conversions of user types * Hana - for using user types instead of tuples * Intrusive - for reusing unused bits in user provided types * Serialization - for out-of-the-box serialization of user types * Spirit - for putting rule results into user provided types without Phoenix or Fusion macro * Test - for outputting content of user provided types * TypeTraits - for traits like has_unique_object_representations in C++14 -- Best regards, Antony Polukhin

5 11

Re: [boost] A GUI Library
by ha ha 09 Nov '17

09 Nov '17

If your library is only dependent on boost, not any other library like nana then it will be better in most of the beginner programmers. IF your library is pre-compiled then it will catch popularity soon, because "allegro 5" is popular for two reasons :- 1. It is very powerful and vast. 2. It is very very easy to deploy, than SDL and SFML. The first choice of the beginner programmers is always SDL but they quickly move to Allegro because of the availability of pre-built binaries. -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

1 0

[devector] optimum growing/insertion policy
by Joaquin M López Muñoz 08 Nov '17

08 Nov '17

Hi, Much an worthy discussion has taken place with respect to growing and insertion policies of boost::double_ended::devector. I think I can justify what the optimum policy is when the overall goal is to minimize number of element movements. What follows is *not* a formal optimality proof, though it's my hunch one could be provided relatively easily. Assumptions * The cost of allocating new memory is negligible when compared to the cost of moving elements around (either intra-buffer or when migrating to a new buffer); so, the growing/insertion policy should focus on minimizing number of elements moved. This implies fully occupying free space before reallocation is *not* the primary goal of the growing/insertion policy. * For the purposes of our discussion, we consider an ever-growing devector without intervening erasures --erasures can be accomodated later as we will see. * Element insertion is modelled as a process where each new insertion happens at a random position within the current devector. The minimal characterization (i.e. its 1st moment in stochastic process theory terminology) is just the percentage R of insertions that happen within the right half of the devector --we call these *right insertions*; left insertions happen then with a frequency L=1-R. push_back is a right insertion, push_front a left insertion. Facts * When a right insertion arrives, if there's free back capacity the optimum insertion policy is to shift elements to the right, as this involves fewer movements than the other way around. The symmetrical applies for left insertions. * If a right insertion at position N arrives and there's no free back capacity (but there is free front capacity), we have only two options: A. Reallocate to get back free capacity. B. Shift elements to the left. The key observation here is that A is cheaper in the long run: as the scenario is one of an ever-growing sequence, reallocation will happen eventually and we can just amortize it in our analysis, so reallocating early saves us the extra movements incurred when left shifting on a right insertion, namely N - (size()-N) = 2*N - size() movements. In fact, we save more than that as insertion is done simultaneously with reallocation, hence no shifting occurs additionally to the (amortized) reallocation cost. All this analysis applies symmetrically to left insertions, of course. * The optimum growing policy is that which maximizes the probability that *both* front and back free capacities get exhausted at the same time. With our 1st moment characterization of the insertion random process, this implies that when reallocating a percentage R of the new space should be devoted to the right side, and a percentage L to the left side. Description of resulting policy * Fix the growing factor to G (this can be 1.5 or 2 or anything greater than one, the actual figure is orthogonal to the discussion). * Maintain a counter right_ of right insertions that gets incremented when a right insertion occurs and *decremented* when an erasure is issued past the middle of the devector. * Right insertions trigger right shifting except when there's no back free capacity, in which case a reallocation is performed. * Left insertions trigger left shifting except when there's no front free capacity, in which case a reallocation is performed. * Reallocation reserves space for G*size() elements: of the resulting G*size()-size() free space, a fraction right_/size() is devoted to back free capacity, the rest to front free capacity. In practice, we may want to keep some minimum space at each end as determined by some empirical threshold. And that's it. Comments welcome. Joaquín M López Muñoz

6 37

Including a system link library for every test, but only on mingw-w64 builds?
by James E. King, III 08 Nov '17

08 Nov '17

Is BOOST_AUTO_LINK supposed to work on mingw-w64 builds with gcc? I'm guessing not since I believe this is a MSVC concept, so I am looking for a bjam recipe that will allow me to add the link library bcrypt.lib to all of the tests in a project's test directory if the build is on a windows system and not using msvc toolset. Are these any examples out there? Thanks, Jim

6 9

[type_traits] is_nothrow_move_constructible gives false positive on GCC 4.7
by Andrzej Krzemienski 08 Nov '17

08 Nov '17

Hi, It seems that boost::is_nothrow_move_constructible sometimes gives false positives on GCC 4.7. See the Git issue for details: https://github.com/boostorg/type_traits/issues/56 Regards, &rzej;

1 0

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