- Boost - lists.boost.org

Boost-GIL GSOC 2020
by Siddhartha Sen 31 Dec '19

31 Dec '19

Hello, I would like to propose an idea for GSOC 2020. I would like to re-implement pre existing features in Boost-GIL for example inverting an image, conversion from black and white to colour and vice versa, etc, but with the usage of parallel programming in order to improve the efficiency and speed things up. This is nothing but an idea merely, as I have some idea with parallel programming beforehand. Could anyone give me some guidance as in how to proceed with this? And also do you all think this is a good enough proposal? I already have built a couple of libraries for image conversion using openmp, but I am not sure whether they are boost compatible or not. Thank You.

2 1

Re: [boost] [review] [STLInterfaces] STLInterfaces review starts today
by Andreas Wass 28 Dec '19

28 Dec '19

This my small review of STLInterfaces, and mainly iterator_interface > - Your name Andreas Wass > - Your knowledge of the problem domain I implement mainly iterators every once in a while, both at work and for personal projects. I have mainly used iterator_interface but used container_interface as well. > - Whether you believe the library should be accepted into Boost (be clear > about this) Yes, it helps cutting down on the amount of boilerplate to write. > In addition, you are strongly encouraged to answer the following questions: > - What is your evaluation of the library's > * Design? The design seems solid > * Implementation? Looks solid as well, only had one issue with container_interface (see below). > * Documentation? It is ok. As someone who isn't implementing containers all that often it would be nice to have signatures as well as expressions listed in the container_interface documentation > - Did you attempt to use the library? If so: > * Which compiler(s)? MSVC 2017 and GCC 9 > * What was the experience? Any problems? One problem with container_interface. See https://github.com/tzlaine/stl_interfaces/issues/12 > - How much effort did you put into your evaluation of the review? About two hours implementing iterators and a container

4 5

[review][STLInterfaces] STLInterfaces review results
by Barrett Adair 26 Dec '19

26 Dec '19

Many thanks are owed to all who participated in the formal review of Zach Laine's STLInterfaces library, especially during this busy holiday season: * Hadriel Kaplan - ACCEPT * Andreas Wass - ACCEPT * Rainer Deyke - ACCEPT * Arthur Gruzauskas - ACCEPT * Krystian Stasiowski - ACCEPT * Daniela Engert - CONDITIONALLY ACCEPT * Gavin Lambert - Technical comments First, a summary of the reviews: 1. Design Reviewers were unanimous in their appreciation for the design. Krystian had the only asterisk about the design, noting that derived class members should ideally be SFINAE-detected, where the library feature would SFINAE where the corresponding required derived feature detection fails. I have a different opinion about this, but we can discuss that elsewhere. 2. Implementation The container_interface destructor and the optional dependency on cmcstl2 were snags for multiple reviewers. Several compile errors were discovered that need to be addressed. 3. Documentation Reviewers found the documentation to be "ok". A common request was for better organization of derived-class requirements, particularly with the container_interface template. Reviewers also lamented the lack of training wheels for the subject matter. 4. Tests Hadriel noted the lack of non-copyable value_type tests, while Daniela noted the lack of Boost.Build support. Hadriel was the only one who commented on the quality of tests ("good"), and the only one who ran them. Arthur did his own testing, to satisfaction. I appreciate the presence of SFINAE-friendliness tests and the continuous integration. 5. Usefulness Reviewers appreciated the usefulness of the library. Arthur is "using it happily", while others found it "very useful", "fairly useful", or of "high" usefulness. However, Krystian's response implied that this library may not be as useful for containers needing extreme performance. The reviews clearly demonstrate a consensus. Accordingly, I'm pleased to announce that STLInterfaces is CONDITIONALLY ACCEPTED as a Boost library. Conditions for acceptance: 1. Remove optional dependency on cmcstl2 (issue #27) 2. Add Boost license comments to all files, including appveyor.yml, .travis.yml, README.md, */CMakeLists.txt (issue #26) 3. Support Boost.Build (issue #25) 4. Replace googletest with Boost equivalent (issue #24) 5. Remove usage of non-existent v2_dtl members in container_interface.hpp (issue #22) 6. Include <tuple> for std::tie usage in C++14 mode (issue #21) 7. Fix dangling parens in container_inteface.hpp:731 (issue #20) 8. Make Concepts usage C++20-conformant (issue #13) 9. Remove the destructor in container_interface (issue #12) 10. Add tests for non-copyable value types (issue #30) Suggestions: 1. Explicitly document the signatures and return types of functions provided by base class templates (issue #23) 2. Mention the C++20 generator pattern in documentation (issue #19) 3. Document the library's interactions with Ranges (issue #18) 4. Remove unnecessary comments (issue #17) 5. Investigate compile error in VS2015 (msvc 19.0.3) due to issues with noexcept() operator in function overloading (issue #16) 6. Rename container_interface to sequence_container_interface (issue #15) 7. Change the 'contiguous' bool to an enum (issue #14) 8. Document the relationship between value_type operator== and containter_interface-defined operator== (issue #11) 9. Improve table/section names for better navigation of container_interface tutorial (issue #10) 10. Clean up BOOST_STL_INTERFACES_DOXYGEN usage (issue #28) 11. Split up fwd.hpp into multiple headers (issue #29) 12. Document optimization trade-offs of proxy_iterator_interface (issue #30) Rationale: 1. Condition #1 is, I feel, the appropriate default as review manager. If Zach feels strongly about keeping the optional dependency on cmcstl2, we should discuss. 2. Unless the library requirements webpage has fallen out of date, new libraries must still support Boost.Build. 3. A not-so-quick grep of current Boost libraries yields no `gtest` results. I assume that we do not allow googletest as the sole test framework in a library. 4. The other conditions should be self-explanatory. Thank you Zach for your contributions, and I look forward to working with you to add this library into Boost. Regards, Barrett Adair

2 2

[review] [STLInterfaces] STLInterfaces review starts today
by Barrett Adair 26 Dec '19

26 Dec '19

Dear Boost, The formal review of Zach Laine's STLInterfaces library begins now, and will run through December 19. Please participate in this review if you can. To submit a review, please reply to this email with the following information: - Your name - Your knowledge of the problem domain - Whether you believe the library should be accepted into Boost (be clear about this) In addition, you are strongly encouraged to answer the following questions: - What is your evaluation of the library's * Design? * Implementation? * Documentation? * Tests? * Usefulness? - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? STLInterfaces is a C++14 library targeting ISO standardization. The following templates are provided, all C++20-friendly: 1. iterator_interface - a modern version of the iterator_facade and iterator_adaptor parts of Boost.Iterator 2. view_interface - a pre-C++20 implementation of C++20's eponymous feature 3. container_interface - a tool to eliminate boilerplate when writing new containers We would appreciate answers to these library-specific questions: - Do you like the name container_interface? sequence_container_interface is more precise, but seems a bit long. - Would you use something like container_interface, but for associative containers? If so, should it assume a node-based interface, a la std::map and std::set? This assumption would preclude alternative associative container-like types, such as flat_map. Code: https://github.com/tzlaine/stl_interfaces Docs: https://tzlaine.github.io/stl_interfaces/doc/html/index.html Thanks, Barrett

9 15

Re: [boost] [config][build] Doc missing in 1.72
by Glen Fernandes 25 Dec '19

25 Dec '19

On 2019-12-24 Glen Fernandes wrote: > Yes. config.htm was a file in boostorg/config until recently. > > Now that it has been removed, meta/libraries.json's documentation > entry needs to be updated: > https://github.com/boostorg/config/blob/develop/meta/libraries.json#L5 > > From "config.htm" to "doc/html/index.html". > > Glen Fixed on develop: https://www.boost.org/doc/libs/develop/libs/libraries.htm (The Config link now goes to the Config documentation). Glen

4 4

Merry Christmas All...
by Ggh 25 Dec '19

25 Dec '19

Hi, Merry christmas to all of you. Happy holidays Cheers Greg Tell me, and I forget. Ask me, and I discover...

1 0

Re: [boost] Proposed legacy macro renaming policy
by Glen Fernandes 25 Dec '19

25 Dec '19

On 2019-12-19 Niall Douglas wrote: > On 18/12/2019 13:51, Glen Fernandes wrote: >> I've fixed the macros in: >> * boostorg/multi_array >> * boostorg/iterator >> * boostorg/parameter >> * boostorg/polygon > > Thanks! > > I reckon with the above about two thirds of the libraries listed at > https://github.com/boostorg/boost/issues/352 are fixed now. > > Niall In addition to the four above, I've now also fixed: * boostorg/bimap * boostorg/lambda * boostorg/graph * boostorg/property_map The rest of the libraries have active maintainers so they should be able to take care of them.

1 0

(no subject)
by Glen Fernandes 25 Dec '19

25 Dec '19

On 2019-12-19 Niall Douglas wrote: > On 18/12/2019 13:51, Glen Fernandes wrote: >> I've fixed the macros in: >> * boostorg/multi_array >> * boostorg/iterator >> * boostorg/parameter >> * boostorg/polygon > > Thanks! > > I reckon with the above about two thirds of the libraries listed at > https://github.com/boostorg/boost/issues/352 are fixed now. > > Niall In addition to the four above, I've now also fixed: * boostorg/bimap * boostorg/lambda * boostorg/graph * boostorg/property_map The rest of the libraries have active maintainers so they should be able to take care of them. Glen

1 0

[config][build] Doc missing in 1.72
by Edward Diener 24 Dec '19

24 Dec '19

In the 1.72 distribution the documentation for config and build are missing.

3 5

[review][fixed_string] FixedString review results
by Joaquin M López Muñoz 22 Dec '19

22 Dec '19

These are the results of the candidate Boost.FixedString review. Thanks to all the people (and there's been many) who contributed. To clear up the tension, let me begin by announcing that: Candidate Boost.FixedString is ACCEPTED into Boost. Acceptance is subject to the authors' addressing of some issues raised during the review that I label as "priority 1" below. *Summary of reviews* We've had 10 full reviews: * Accept: Deniz Bahadir, Emil Dotchevski, Gavin Lambert, JeanHeyd Meneide, Paul A. Bristow, Peter Dimov, Peter Koch Larsen. * Conditionally accept: Zach Laine. * Reject: Andrzej Krzemienski, Phil Endecott. Zach's conditions to acceptance seem minor and easily addressable to me. Andrzej based his rejection on a perceived lack of clarity as to what the actual pitch of the library is, which ultimately boils down to the issue of throwing/asserting on capacity overflow: my impression is that a strong pitch, if not a universally acclaimed one, emerged during discussions. Finally, Phil voted to reject but then went on to state that he would accept based on a number of "minimally sufficient" conditions that are trivial to meet (or even have been already implemented by Krystian). All in all, I think it is a reasonable compromise to grant acceptance based on the resolution of a number of important issues, listed below. *Issues* I've classified issues in three different priorities: * Priority 1: to be solved *before* inclusion into Boost. * Priority 2: to be addressed somewhere in the future. * Priority 3: anecdotal or without clear support from the community, to be addressed at the authors's discretion. * Priority 1 issues* 1. CMakeLists.txt should either be made generic or removed from repo (it is currently a specific thing for Visual Studio). 2. Choose a name for the component. Some consensus arose that naming should follow std::string's and be of the form basic_foo<...> with aliases foo, wfoo, etc. As for "foo", the following candidates have been proposed: * static_string * fixed_capacity_string * array_string * static_capacity_string * inplace_string * capped_string * bounded_capacity_string * bounded_string To be clear, I don't think any of these is clearly more popular than the rest, so it is up to the authors to make up their mind. 3. constexpr as much as possible, taking into account that, pre C++20, this requires zero initialization of the data array. 4. noexcept as much as possible and, in principle, at least as much as std::string. 5. Provide hash overloads. Up to the authors if they want to cover Boost.Hash as well. 6. Determine the exact behavior on capacity overflow. I think *some* partial consensus arose around throwing via boost::throw_exception so as to provide an opt-out mechanism for exception-handicapped scenarios. This has been the most contentious issue during the review but I think the authors are in their right to decide on throwing much as anyone can decide otherwise and propose what would be basically a different library. 7. Make substr return a fixed_string rather than a view, and additionally provide a view-returning subview member function. 8. State clearly on the docs what C++ version is required. 9 There are wrong "size() + m > max_size()" checks (they could overflow) in the code. 10. to_fixed_string should be a set of overloads mathing those of std::string. 11. There's an issue around some detail::is_input_iterator alias that Zach asked be clarified. 12. Compile-fail tests should be added to verify that those functions with constraints are correctly constrained. *Priority 2* 13. Determine if fixed_string<0> should be specialized or not to make it more memory efficient. This raises potential issues in the uniqueness of the pointer returned by data(). 14. Determine if operator+(fixed_string,fixed_string) should be provided. My impression is that people generally wanted this, and I've been tempted to raise this to priority 1. 15. Optimize the type of the internal size data member when size_t is larger than necessary. 16. BOOST_FIXED_STRING_USE_BOOST is unconditionally defined within the code. The authors should clearly state what this is for and let the user configure the library to use with/without Boost or, else, remove the thing entirely. 17. Source code organization (three equally named files, detal and impl folders), raised some eyebrows. Some (including Vinnie) favor a single-file implementation. 18. Docs should be more C++ standard-like and provide a synopsis. Vinnie has indicated they may abandon Doxygen in favor of asciidoc to produce better-quality docs. In general, people were not enthusiastic about the documentation. 19. The current monolithic test should be split up in lighter, more manegeable test files. Peter Dimov suggested some additional improvements on the testing part. * Priority 3* 20. Provide a literal operator"" 21. Should traits parameter be removed? 22. Store size (as capacity-size) in the last char of the data array, so as to save one memory byte. This might affect performance, though. 23. Add functions for checking remaining capacity. Thanks to Krystian and Vinnie for their work! And to everybody who has contributed to this really interesting review. Best regards, Joaquín M López Muñoz Review manager for candidate Boost.FixedString

7 12