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

[review][Fit] Fit Review Results
by Matt Calabrese 25 Sep '17

25 Sep '17

Hello everyone, It is my privilege to announce that the Boost library count will once again be incremented as Paul Fultz II's library Fit has been accepted into Boost without conditions. Further details about this decision follow, but before that I'd like to thank Paul for all of the hard work he has put into Fit. Thanks also to everyone who participated in the review, with additional thanks to Vicente who was the review manager for the previous Fit review and who also provided a very detailed review and discussion during this review period. //////////////////////////////////////////////////////////////////////////////// Overview //////////////////////////////////////////////////////////////////////////////// Complete Reviews Considered: Zach Laine: Accept Vicente J. Botet Escriba: Accept John P. Fletcher: Accept Robert Ramey: Accept Jason Rice: Accept Barrett Adair: Accept Lee Clagett: Accept Glen Fernandes: Accept Louis Dionne: Accept Partial Reviews/Discussions Considered: Edward Diener Andrea Bocci Further Discussions (Previous Review): Steven Watanabe Peter Dimov Vladimir Batov Gavin Lambert Rob Stewart Bjorn Reese Manu Sanchez Artyom Beilis //////////////////////////////////////////////////////////////////////////////// Summary //////////////////////////////////////////////////////////////////////////////// Though not all responders reviewed every single aspect of the library, the reviews together adequately covered everything that is necessary for a decision to be made. This decision is made with additional confidence coming from usage of the library by some reviewers going back since during or before the initial review in early 2016. //////////////////////////////////////////////////////////////////////////////// Improvements Since Previous Review //////////////////////////////////////////////////////////////////////////////// This time around we received several more complete reviews than in the previous review period making it easier to be confident in a decision. A couple of notable changes since the 2016 review include: * Improved documentation * Default semantics for "capture" no longer try to determine whether to capture by reference or by value based on the argument being an lvalue or an rvalue (users can still get this via basic_capture) * Improved ADL awareness (internal calls are qualified) Throughout all of the discussions in this second review period, there were no explicit rejections of the library as a whole, though there were several recommendations from participants. A selection of those are listed here, though no changes are strictly required for acceptance: //////////////////////////////////////////////////////////////////////////////// Current Concerns //////////////////////////////////////////////////////////////////////////////// ////////// Design concerns: * Inheritance from user-callables has some potential pitfalls * Generated "infix" operators are "gimmicky" and don't add much value/may cause confusion * Placeholders should live in their own namespace ////////// Documentation concerns (not a complete list): * More examples requested * It is not always clear what files need to be #included for certain facilities in early examples * Better rationale for ConstFunctionObjects * Raw code is not linked from the examples ////////// Suggested name changes from reviewers: * Suggested rename of "partial()" to "partial_apply()" or "curry()" * Suggested rename of "conditional()" to "invoke_first()" or "call_first_of()" * Suggested rename of "apply" to "invoke" * Refer to "Callables" instead as "Invocables" (due to C++17 direction) * Library name "Fit" is not indicative of what it provides //////////////////////////////////////////////////////////////////////////////// Regarding the Author //////////////////////////////////////////////////////////////////////////////// Paul has been active in the Boost community for several years now. He is aware of his responsibilities going forward and I am confident that he will be a reliable maintainer for Fit for the foreseeable future (or whatever the library may be called). //////////////////////////////////////////////////////////////////////////////// Comments on the Name Boost.Fit //////////////////////////////////////////////////////////////////////////////// Note that what I say here is my personal opinion as a member of the community and does not necessarily reflect the opinions of others in the community nor of those in the steering committee. A few reviewers voiced that they would like to see a change of the library name "Fit". While multiple people did suggest this, my opinion is that this should be up to the author to choose whether or not he will change the name before it is added to boost and so I do not think it would be appropriate for us to strictly require or encourage such a change. If the author found the arguments against the name compelling, then he is welcome to change the name, but he should not feel obligated to do so. As a quick note on that, we have several high quality and highly regarded libraries in Boost with names that may not directly tell users what the library is for. Based on their popularity, I do not believe that it has significantly negatively affected their usage or ability to be found. A library name also may be important to an author as a creative outlet and I think it would be... poor form us to force such a change in this particular case and in other cases unless there are very strong reasons (i.e. the name is overly or intentionally misleading or there are legal concerns). I am not convinced that the current name is misleading enough to strictly require a change. As for existing precedent, some examples of libraries already in Boost with names that do not directly tell the user what the library is for include some of Boost's most highly regarded libraries such as Boost.Spirit (including Qi and Karma), Boost.Phoenix, Boost.Wave, Boost.Hana, and the recently accepted Boost.Beast. //////////////////////////////////////////////////////////////////////////////// Thanks again to everyone who participated in this review and in the previous review, and once again, congratulations to Paul on his library's acceptance into Boost. -- -Matt Calabrese

4 3

[utility] [config] value_init tests on msvc-14.0, 14.1
by Peter Dimov 24 Sep '17

24 Sep '17

Currently, value_init_workaround_test.cpp fails on both msvc-14.0 and 14.1, because in: #ifdef BOOST_DETAIL_VALUE_INIT_WORKAROUND_SUGGESTED // One or more failures are expected. return num_failures > 0 ? EXIT_SUCCESS : EXIT_FAILURE; #else // No failures are expected. return num_failures == 0 ? EXIT_SUCCESS : EXIT_FAILURE; #endif failures are supposedly expected (BOOST_DETAIL_VALUE_INIT_WORKAROUND_SUGGESTED is defined), but there are none. BOOST_DETAIL_VALUE_INIT_WORKAROUND_SUGGESTED is controlled by BOOST_NO_COMPLETE_VALUE_INITIALIZATION, which is defined on 14.0/14.1. The Config macro is defined because - presumably - msvc 14.0/14.1 fail the Config test for value initialization, boost_no_com_value_init.ipp. But this test is much more comprehensive than the value_init one. So to fix the value_init_workaround_test.cpp failure, we need to at minimum move one failing test case from the Config test to the value_init one.

2 3

Modular Packages on Conan.io
by Rene Rivera 24 Sep '17

24 Sep '17

One of the most requested feature from Boost users is having a "modular" distribution. I'm happy to announce that there are now modular packages available when using the Conan package manager from the Bincrafters team < http://bit.ly/2wM5AdT>[1]. Using the packages requires no prior setup other than the Conan tool. Immediately available are all 130 libraries from the 1.64.0 release. And in a few days we will follow up with the same for the 1.65.1 release. For help using the packages you can bug the Bincrafters team <http://bit.ly/2xWEGEX>[3] in the #conan cpplang.slack.com channel < http://bit.ly/2hnMB3o>[4]. Conan is a C/C++ (and more) package manager that supports an open ended set of build system and tool integrations including: VisualStudio, Xcode, CLion, Ninja, QMake, Premake, and yes even CMake <http://bit.ly/2xzhpbg>[2]. [1] <https://bincrafters.github.io/2017/09/22/boost-modular-packages-conan/> [2] <http://docs.conan.io/en/latest/integrations.html> [3] <https://bintray.com/bincrafters/public-conan> [4] <https://cpplang.slack.com/messages/C41CWV9HA> -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

4 5

Including open source, non-copyright, no warranty in a boost library
by James E. King, III 24 Sep '17

24 Sep '17

Hello, I'm working on refactoring boost::uuids::name_generator to have a configurable hash algorithm through a template concept. RFC 4122 allows for two hashing algorithms, MD5 and SHA1. The current implementation only does SHA1, however I want to add MD5 for completeness (and I want to prepare for the eventual successor to SHA1 in the next RFC for UUID). I found an open source MD5 implementation of RFC 1321 at the following location and I was wondering if there are rules against bringing it into boost as a detail implementation? http://openwall.info/wiki/people/solar/software/public-domain-source-code/m… Thanks, Jim

4 3

BCM - Boost CMake Modules request for endorsement
by paul 22 Sep '17

22 Sep '17

Hi, So the Daniel Pfeifer has agreed to be the review manager for the Boost Cmake Modules. I would like ask for an endorsement so we can schedule a formal review for BCM. Thanks, Paul .

5 7

Travis/Appveyor improvements for the superproject
by Peter Dimov 22 Sep '17

22 Sep '17

Travis and Appveyor tests for the Boost superproject have been improved to automatically run the tests for the library mentioned in the commit message. For example, if the message is "Update iterator from develop", the corresponding CI job runs the tests of the Iterator library (among other things). This is a bit redundant if the library itself has Travis/Appveyor set up, but keeping an eye on https://ci.appveyor.com/project/boostorg/boost/history and https://travis-ci.org/boostorg/boost/builds can't hurt. For example, Appveyor says that Iterator fails a test on msvc-12.0 (Visual Studio 2013): https://ci.appveyor.com/project/boostorg/boost/build/1.0.3744-develop and Utility fails a test on msvc-14.0/msvc-14.1: https://ci.appveyor.com/project/boostorg/boost/build/1.0.3765-develop

9 16

[review][Fit] Review of Fit starts today : September 8 - September 17
by Matt Calabrese 22 Sep '17

22 Sep '17

A formal review of the Fit library developed by Paul Fultz II starts today, September 8, and runs through September 17. A branch has been made for the review. 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/ Anyone who is able to provide an assessment of the design, implementation, and/or docs can participate in this review. Usage experience is not absolutely necessary to give feedback, but is highly recommended if you are writing a review. Discussions about aspects of the library are welcome even if a complete review is not presented, though participants are asked to please state whether they would like to accept or reject the library before the deadline of September 17, paying close attention to the questions raised at the end of this email. The success of Boost is partially a result of the quality review process which is conducted by the community. You are part of the Boost community. We will be grateful to receive a review based on whatever level of effort or time you can devote. This is the second time that Fit will go through the review process, with the previous time being in March of 2016. The result of the initial review can be found here: https://lists.boost.org/Archives/boost/2016/04/228770.php In this second review, those who choose to participate should be as rigorous as they'd be in any other review, but are also encouraged to voice whether or not the concerns from March of 2016 were addressed. The following is a brief description of the library from its author: ==================== Fit is a header-only C++11/C++14 library that provides utilities for functions and function objects, which can solve many problems with much simpler constructs than whats traditionally been done with metaprogramming. Fit is: Modern: Fit takes advantages of modern C++11/C++14 features. It support both constexpr initialization and constexpr evaluation of functions. It takes advantage of type deduction, varidiac templates, and perfect forwarding to provide a simple and modern interface. Relevant: Fit provides utilities for functions and does not try to implement a functional language in C++. As such, Fit solves many problems relevant to C++ programmers, including initialization of function objects and lambdas, overloading with ordering, improved return type deduction, and much more. Lightweight: Fit builds simple lightweight abstraction on top of function objects. It does not require subscribing to an entire framework. Just use the parts you need. Fit is divided into three components: Function Adaptors and Decorators: These enhance functions with additional capability. Functions: These return functions that achieve a specific purpose. Utilities: These are general utilities that are useful when defining or using functions. Requirements This requires a C++11 compiler. There are no third-party dependencies. This has been tested on clang 3.5-3.8, gcc 4.6-6.2, and Visual Studio 2015. Gcc 5.1 is not supported at all, however, gcc 5.4 is supported. Contexpr support: Both MSVC and gcc 4.6 have limited constexpr support due to many bugs in the implementation of constexpr. However, constexpr initialization of functions is supported when using the FIT_STATIC_FUNCTION and FIT_STATIC_LAMBDA_FUNCTION constructs. Noexcept support: On older compilers such as gcc 4.6 and gcc 4.7, noexcept is not used due to many bugs in the implementation. Also, most compilers don’t support deducing noexcept with member function pointers. Only newer versions of gcc(4.9 and later) support this. ==================== 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

13 39

Crypto/hashes library?
by James E. King, III 21 Sep '17

21 Sep '17

Hello, The boost uuid module contains an implementation of the sha1 hash algorithm for purposes of generating a uuid from arbitrary input. I've opened an issue on github to make the hash algorithm configurable: https://github.com/boostorg/uuid/issues/26 I was hoping to find a concept and implementation of a few hashes somewhere in boost that could be used instead, however I haven't found any. Back in 2010 someone posted a link to a "boost::hashes" repository but I was unable to see what the outcome of the discussion was other than that it was not included. A collection of hashing algorithms that are well tested would be quite useful in a number of ways; and I like the hash size template style used in the repo from 2010: https://svn.boost.org/svn/boost/sandbox/hash/ Indeed there's mention of a discussion about the proper placement of sha1 inside boost::uuid in there: https://svn.boost.org/svn/boost/sandbox/hash/libs/hash/doc/html/rationale.h… So I was curious where that effort ended up, and if there was a resolution on whether an independent library for hashing was ultimately something that folks wanted to pursue or avoid. Thanks, Jim

8 16

[move] [container] workaround for incorrect [-Wignored-attributes]
by Groke, Paul 21 Sep '17

21 Sep '17

Hi, we've stumbled over a supposed bug in GCC 6 that generates incorrect [-Wignored-attributes] warnings. Using anything in Boost that relies on boost::move_detail::aligned_storage (like boost::container::small_vector), with a small enough type, will trigger this warning when compiling for certain architectures with at least GCC 6.2~6.4. Affected architectures are e.g. SPARC and ARM - not affected are x86 and ARM64. GCC bug ticket: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82270 It would be possible to work around this issue by changing the implementation of boost::move_detail::aligned_storage_impl so that the aligned type no longer carries the attribute(aligned) itself, but just contains a member which carries that attribute. If I understand this correctly this should have the same effect (barring compiler bugs). Question: Would a pull request for such a change be welcome? Regards, Paul Groke

2 1

Mini review of the Fit library
by Glen Fernandes 21 Sep '17

21 Sep '17

What follows is my mini review of the Fit library. I had no time to write a full review, but feel that most of my points have been covered by others in both the first and this second review. A. Should the library be accepted into Boost? Yes; I vote to accept Fit - with no conditions for acceptance. B. What is your evaluation of the design? I found it: 1. Practical: For facilities like BOOST_FIT_LIFT. 2. Innovative: For facilities like infix(). And overall useful. C. What is your evaluation of the implementation? Good. Appears to be correct C++ code, and is definitely written in a very maintainable way. Ordinarily I'm in favor of not seeing macros used for what is accomplished by FIT_INHERIT_DEFAULT, FIT_INHERIT_CONSTRUCTOR, and similar, but this is a minor thing, and it does serve to make the code smaller and easier to review. I also like that the lowest version of C++ standard support required is C++11 (and not higher), as I am still aware of a large enough pre-C++14 user base that do have access to and use Boost libraries. D. What is your evaluation of the documentation? Excellent. Better than what I generally write. Useful enough for me, and in my opinion, sufficient for understanding the library and learning how to use it - for any user that takes the time to read through it all. E. What is your evaluation of the potential usefulness of the library? I believe it to be useful, and I know of at one developer that I have suggested Fit to, that has started using it - and another that would like to start using it if it is included in a Boost release (for which their organization has blanket approval to use). F. Did you try to use the library? With which compiler(s)? Did you have any problems? Not recently, but Yes. With g++ 6.3. I encountered no problems. G. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I had spent at least 3+ hours looking into Fit with the intention of reviewing it for my own use, and learning how one part of it was implemented. I did not have a chance to spend as much time as I would normally have to write a full review of the library. H. Are you knowledgeable about the problem domain? Familiar with enough functional programming design and generic programming to appreciate the library. Other notes: No concern about the name. We have Beast, Hana, Spirit; Fit is a fine enough name, and boost::fit:: is a convenient enough prefix. Glen

2 1