- Boost - lists.preview.boost.org

[review] Final Notice! Fit Review Ends Today!
by Matt Calabrese 20 Sep '17

20 Sep '17

Hi everyone, The formal review of the Fit library is ending today, September 20th. For anyone who was waiting until the last minute to submit a review, this would be it. Anything that you can provide is helpful in making a decision, even if you do not write a complete review of the entire library. You can find Fit for review at these links: Source: https://github.com/pfultz2/Fit/tree/boost Docs: http://pfultz2.github.io/Fit/doc/html/doc/ Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost library. Please be explicit about your decision. Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? - Were the concerns from the March 2016 review of Fit addressed? More information about the Boost Formal Review Process can be found here: http://www.boost.org/community/reviews.html Thank you for participating! -- -Matt Calabrese

1 0

Re: [boost] [review][Fit] Review of Fit starts today
by Jason Rice 19 Sep '17

19 Sep '17

Please consider this review for the proposed Boost.Fit library. I recommend the review manager ACCEPT this library for inclusion in Boost without condition. # What is your evaluation of the design? - Making high order functions easier and more concise is a good idea. - I like the point-free programming features. - Some of the names, conventions, and errors would take any kind of user some getting used to. - A version of `alias_value` that works in a generic context where the type might not be an alias would be more useful I think. # What is your evaluation of the implementation? - The code is consistent across implementations and the files are pretty flat - Each function can be included independently which is nice. - It appears that there is some effort towards making errors easier to read. For instance, I called `fit::partial` with too many arguments and the error was "error: no member named 'fit_function_param_limit'" - There is some readability issues due to compiler compatibility support and specific compiler error workarounds. - I noticed `fit::decay` is not used in the tests at all. It gets included in `example.h` but is never used. # What is your evaluation of the documentation? - I like that the documentation is easy to read in the comments of each file. - Some of the wording in the descriptions weren't very helpful for me personally, but the "Semantics" section seemed to always get the point of the function across. # What is your evaluation of the potential usefulness of the library? - It seems parts of the library might not be that useful if you have constexpr lambdas, but I believe there are still features that enable more concise coding even against latest C++17 features. - I will probably use this library now that I am familiar with it. # Did you try to use the library? With which compiler(s)? Did you have any problems? - I made a couple of my own examples. - I used a fairly recent fork of clang trunk with c++1z. - BOOST_FIT_RETURNS *crashed the compiler* when I was trying to construct an std::array with some pack expansion. It looked like it crashed the parser. # How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - I spent a couple of hours looking at the docs in the source and making my own test programs to see how it could be used. # Are you knowledgeable about the problem domain? - I've used Boost.Hana a lot with its "functional" features. - I've done a lot of point free programming with RamdaJS in Javascript # Were the concerns from the March 2016 review of Fit addressed? N/A For what it's worth here is a link to some of my attempts to sample the library: https://gist.github.com/ricejasonf/9bfd233b3bc282eae9ecb8bc3198d948 Thank You, Jason Rice

2 1

[Container] small flat set ?
by Phil Endecott 18 Sep '17

18 Sep '17

Dear all, boost::container::small_vector and boost::container::static_vector are great. boost::container::flat_set is great too. But today I need a small_flat_set! And I don't think it's possible to compose flat_set and small_vector. (flat_set can use a custom allocator, but it can't take a custom implementation type in the way that, for example, std::priority_queue can.) Having said that, maybe composing flat_set and small_vector (or static_vector) isn't the optimum solution for the case where I will store something like 0...4 ints; I suspect that linear search in an unordered sequence will be quicker. But that gets complicated if you need iterators with the normal behaviour. Any thoughts? Regards, Phil.

5 14

Last Day for Boost Community Dinner Sign up
by Jon Kalb 18 Sep '17

18 Sep '17

Boost Developers, Today is the last day to register for the Boost Community Dinner at CppCon. http://sched.co/Bhcr You do not need to be registered to attend CppCon to register for the Boost Community Dinner: https://cppcon.org/registration/ If you are going to be in the Seattle area a week from Tuesday, join us for a rare face-to-face get together of the Boost Community. See you there. Jon

1 0

[docs] Documentation on Github?
by John Maddock 18 Sep '17

18 Sep '17

I notice that a few libraries are serving their documentation pages on github, for example http://boostorg.github.io/quickbook/doc/html/index.html How is this being done? Thanks! John. --- This email has been checked for viruses by AVG. http://www.avg.com

8 8

[review] Reminder that Fit Review Is Ending Soon. Please review!
by Matt Calabrese 16 Sep '17

16 Sep '17

Hi everyone, The formal review of the Fit library was scheduled to end tomorrow, September 17. At this point we do not have very many reviews and so we are extending the review period until the 20th. Anyone who can is encouraged to participate. Anything that you can provide is helpful in making a decision, even if you do not write a complete review of the entire library. You can find Fit for review at these links: Source: https://github.com/pfultz2/Fit/tree/boost Docs: http://pfultz2.github.io/Fit/doc/html/doc/ Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost library. Please be explicit about your decision. Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? - Were the concerns from the March 2016 review of Fit addressed? More information about the Boost Formal Review Process can be found here: http://www.boost.org/community/reviews.html Thank you for participating! - Matt Calabrese

1 0

[winapi] Enable Travis and AppVeyor
by Andrey Semashev 16 Sep '17

16 Sep '17

Hi, I'm trying to enable Travis and AppVeyor builds for Boost.WinAPI, and Travis says that I need admin rights on the project to do it: https://travis-ci.org/boostorg/winapi I don't know if AppVeyor also needs admin rights, maybe someone with more experience could clarify. Could I have the admin rights for Boost.WinAPI? Or maybe boostorg admins could do the necessary steps to enable the project in Travis and AppVeyor? Thanks.

2 7

Searching for Review Manager for reflection library without macro
by Antony Polukhin 15 Sep '17

15 Sep '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… Anyone wishing to become 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

7 9

boost::random, header-only, boost::uuids::detail::seed_rng, and UWP development
by James E. King, III 14 Sep '17

14 Sep '17

Hi folks, It looks like the only reason boostorg/random is not a header-only library is due to random_device (it is the only src/ file: https://github.com/boostorg/random/tree/develop/src) The older WinCrypt calls are not available in some Windows platforms going forward, so this is going to become a problem pretty quickly for the community. In the boostorg/uuid library there is a seed_rng class which is doing similar things (however providing more entropy) and the library is header-only. In addition there are two filed defects - one in Trac and one in github issues, about uuid being incompatible with UWP applications (that's Windows universal apps). In uuid, I started adding support for BCrypt which is a Windows API supported on later versions of Windows, and once I changed my build flags to target Windows 10 and WINAPI_FAMILY_APP, I started getting build failures in random_device. On further inspection it looks like the random library doesn't have support for BCrypt yet, and even worse as a source library one would need to build two variants - one for WinCrypt and one for BCrypt to support older and newer windows platforms. There are also some implications on MinGW, as the older original MinGW has support for WinCrypt and MinGW-64 supports both. I'm going to propose that the implementation from boost::uuids::detail::seed_rng be moved into boost::random as the new random_device implementation. At the same time, boost::random will become header-only, and thus support setting _WIN32_WINNT at build time of consuming applications properly, and therefore support new Windows platforms properly. At the same time I would like to change seed_rng such that it no longer silently ignores some return values, and does not disable any compiler warnings (deprecations, currently). Thoughts? Thanks, - Jim

6 15

C++17 detection
by Robert Ramey 14 Sep '17

14 Sep '17

How do I get ready for C++17? I have a piece of code which requires C++14. I want to use something from C++17 but I also want my code to work now. So I have #if C++14 being used namespace std { // implement C++ function } // std I've looked in the documentation for Boost.Config and can't find any hints there. What is the best way to do this? Robert Ramey

14 25