December 2019 - Boost - lists.preview.boost.org

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 199

What happened to Boost.Nowide?
by Alexander Grund 08 Jan '20

08 Jan '20

Hi, I'm a user of (a fork of) Boost.Nowide and already fixed some issues I found and was looking into getting them upstream. I also wanted to know, if it is finally in Boost. Unfortunately this does not seem to be the case. I found https://lists.boost.org/Archives/boost//2017/06/236475.php which accepted it into Boost. This is from mid-2017 and nothing has happened since. Does anyone know what the status of Boost.Nowide is? It seems the filestream parts are now incorporated into Boost.FileSystem. So it seems only cin/cout/cerr, the args wrapper and the C-functions (fopen, ...) are missing. Especially the first 2 are very useful in writing cross-platform code. Might those be integrated into some other Boost Library? Thanks, Alex

4 16

Boost ASIO
by live man 03 Jan '20

03 Jan '20

Hi, We have been using Boost for our firmware product which runs in ARM processor. However for development we make use of Visual Studio IDE. We also have our own TCP / IP suite which defines its own socket.h file. We are facing issue related to using Boost ASIO in Windows development platform. It seems that the library by default includes windows networking header files - which we do not want. Instead we want Boost ASIO to make our own library socket headers and declaration. We noticed that if we include Boost ASIO and our TCP / IP socket declaration we get re-definition error and compilation fails with lots of errors? Please let us know how we can resolve the issue with the objective mentioned above? Thanks in advance. Regards, Prakash

2 2

Recomended way of generating documentation
by Alexander Grund 01 Jan '20

01 Jan '20

Hi, I'm currently in the process of generating documentation in a Boost usable format and got a couple questions. The documentation is currently in-source in Doxygen format and has a markdown file for the start page. 1. Which aliases do I need and for what? I've seen boostdoc and boostrelease but couldn't find a description what and why they are 2. Where do the documentation files need to go? It seems using BJam naively outputs them to bin.v2 not to the libraries doc folder which I'd even see useful because generated files should not clobber the source tree 3. What benefit is there going from Doxygen (over multiple conversions) to boostbook? Can't I just go from Doxygen to HTML? 4. If the above: Calling `doxygen mylib.html` in BJam generates a mylib folder and a mylib.html redirecting into that folder. Both hardcoded to go into a subfolder of bin.v2. How is that useful/useable? Wouldn't I want a 'html' folder and an index.html redirecting to the index.html contained or no redirection file at all? 5. As I'm thinking about calling doxygen manually: Do I need to do anything so e.g. mylib shows up in boost/doc/html? Why is only a subset of the libraries there? Thanks for any help or pointers! Alexander Grund

6 5

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

[gsoc2020] New here
by Siddhant Jain 22 Dec '19

22 Dec '19

Hi, my name is Siddhant I am a first year CS student at IIIT Hyderabad. I am interested in learning more about and contributing to boost. I have visited the obvious beginners links but I am unable to grasp the library to the level where I can contribute code. What would be the suggest plan of action to get comfortable with reading and write code used in boost. I am interested in working on Boost.geometry and/or Boost.real. Thanks

1 0

[move][core] boost::swap() vs boost::adl_move_swap()
by Andrzej Krzemienski 21 Dec '19

21 Dec '19

Hi Everyone, I am seeking an advice. I recently got this pull request: https://github.com/boostorg/optional/pull/77 changing the boost::swap() to boost::adl_move_swap() because it should compile faster. Is there any recommendation for Boost libraries which one to prefer and under what circumstances? boost::adl_move_swap() seems to allow moves rather than copies in more cases. On the other hand boost::swap() seems to have other improvements, like BOOST_GPU_ENABLED. Regards, &rzej;

2 1

boost::python::def_visitor alignment / padding crash.
by Janek Kozicki 20 Dec '19

20 Dec '19

I have discovered an alignment related bug in boost::python::def_visitor For a very detailed description see https://gitlab.com/libeigen/eigen/issues/1795 * a minimal failing example: https://gitlab.com/cosurgi/minieigen-real/blob/minimalFailingExample/src/mi… * and the failing CI pipeline: https://gitlab.com/cosurgi/minieigen-real/pipelines/104745741 Initially I thought that it was related with libeigen. But it turns out that it crashes even without libeigen, when just using boost::multiprecision::float128. The code crashes with g++ 8.3.0 and works with g++ 9.2.1 boost version 1.67 is used there. should I open an issue on boost github? best regards -- # Janek Kozicki http://janek.kozicki.pl/

1 1

[appveyor] Really slow turnover
by Edward Diener 20 Dec '19

20 Dec '19

When I started out in computer programming some 40 years ago you could submit a job, with some JCL, on an IBM mainframe computer via an input card reader and you were lucky if you got back the result a day later. How happy I was when I went to microcomputers and could get almost instantaneous results from any programming attempt. Fast forward to now, some 40 years later, and it seems like nothing changes, despite the great advancement in computer technology and online access in our current age. Attempting to run CI using Appveyor literally has jobs queued pending a run for days and days. Surely there must be something better in this day and age than this ridiculously slow internet service. Is it 1979 again ?

7 18

[review][STLInterfaces] review extended to Dec. 23
by Barrett Adair 20 Dec '19

20 Dec '19

The formal review of STLInterfaces is extended to December 23. Please consider submitting a review if you can.

1 0

Re: [boost] Jason is getting MARRIED!
by Bjorn Reese 20 Dec '19

20 Dec '19

On 11/16/19 7:09 PM, Vinnie Falco via Boost wrote: > My JSON library is going to propose to Boost soon, is there anyone who > might be willing and able to function in the role of review manager? Before we get to that point, there are some questions that the community should address. These days there are a huge number of JSON libraries out there. Some focus on features (e.g. binary JSON or JSONPath), others on performance, and others on user-friendliness. What competitive edge should a potential Boost JSON library offer? Which use cases should a potential Boost JSON library support? Should the library work seemlessly with standard algorithms? Should it be possible to create parser combinators? Should there be a JSON archive for Boost.Serialization? Should it replace parts of Boost.PropertyTree? PS: On a procedural note, you need an endorsement of the library before seeking a review manager.

10 68

GSoc 2020
by Aniswar SK 19 Dec '19

19 Dec '19

Hello everyone, I am Aniswar Krishnan, a 2nd year Computer Science student at Indian Institute of Technology, Madras. I am have been coding in c++ and python for the past 15 months. I am interested in Mathematics and Algorithms and have done courses on same along with Data Structures, Linear Algebra. I got interested int the projects like Boost.Real and Boost GIL and would like to contribute more to the community. Please guide me and share the relevant resources needed. Will be grateful. Regards, Aniswar Krishnan II Year Computer Science IIT Madras Chennai, Tamil Nadu

3 2

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

18 Dec '19

I've fixed the macros in: * boostorg/multi_array * boostorg/iterator * boostorg/parameter * boostorg/polygon Glen

2 1

What to do about Boost libraries which use user-defined macros which are not BOOST_ prefixed
by Niall Douglas 18 Dec '19

18 Dec '19

Acting on guidance given to my recent supply to this list of unprefixed macros, namespaces etc injected into the global namespace by Boost, I have logged a list of all issues with each library, and linked to all those from a single issue logged at https://github.com/boostorg/boost/issues/352. A problem has arisen which requires input from boost-dev. Some Boost libraries define as part of their public API a non-BOOST_-prefixed macro which changes the definition of their header files e.g. PHOENIX_LIMIT (just to be clear, Phoenix is not the only library doing this) If we change such macros to be like BOOST_PHOENIX_LIMIT instead, all existing code using Boost which sets PHOENIX_LIMIT would potentially *silently* break. What we could decide to do instead is: #if defined(PHOENIX_LIMIT) && !defined(BOOST_PHOENIX_LIMIT) #error In Boost 1.xx PHOENIX_LIMIT was renamed to BOOST_PHOENIX_LIMIT. Please upgrade your code to reflect the new name. #endif Or one could just leave PHOENIX_LIMIT named as is. What would Boost developers prefer we do? Niall

8 19

Re: [boost] [review] [STLInterfaces] STLInterfaces review starts today
by Hadriel Kaplan 18 Dec '19

18 Dec '19

Howdy, For this review I've really only tried out the iterator_interface part. I'm sorry I can't provide feedback on the container_interface nor view_interface, as I just don't have the free cycles. > - Your name Hadriel Kaplan > - Your knowledge of the problem domain I've been using boost's iterator_facade and adaptor for a long time; I've written my own custom iterators as well, of both traditional and proxy-types. The usual stuff. > - Whether you believe the library should be accepted into Boost (be clear about this) Definitely. It could use word-smithing and minor cleanup stuff, but presumably that happens later. (?) > - What is your evaluation of the library's > * Design? Good overall. > * Implementation? Good. I've got some nitpicks, but honestly none are a big deal. minor nitpicks: 1) I didn't use the proxy_iterator_interface one, only looked at the code. The proxy_arrow_result storing a local T value that it only returns a pointer to, means it's not optimal in some cases. Obviously for something like std::vector<bool> it won't matter, but some value-types are not so lightweight. On the other hand, it looks like we can specialize this for our type (or not even use proxy_arrow_result to begin with)? 2) Can the stuff in fwd.hpp be split out? I could be wrong, but I don't think most of it is needed/used by iterator_interface, and only used by the other two, correct? Reducing what gets included would be nice, for people who don't need the container/view stuff. The old boost iterator_facade/adaptor headers included so much that it drove some people to stop using them; for example see the comments here: https://github.com/facebook/folly/blob/master/folly/detail/Iterators.h 3) This lib hasn't been tested for C++20, and obviously can't be yet, but it makes assumptions that it can safely replace some of its internals with C++20's new ones. Things like concepts and ranges. I'm not sure that's advisable, until all the major compilers support them and can be tested. It would be a shame if people using this lib can't upgrade to C++20 because it breaks this lib, until they upgrade boost as well. (not a big deal, just more noting it) 4) The files use a macro to control doxygen output. Is this still required for boost libs? Doxygen has had the cond/endcond commands for a long, long time. It's kinda ugly to see these macros, and kinda silly that everyone's compiler will be evaluating them all the time. (I know that's super-nitpicky) 5) I assume all the _has_include(<stl2/ranges.hpp>) checks will be removed, since that's a thirdparty header? 6) This lib requires C++14, but I don't see a macro checking that anywhere and providing a simple error to the user. 7) I can't decide if the BOOST_STL_INTERFACES_STATIC_ASSERT_ITERATOR_TRAITS() thing is a good idea or a waste of time. I tried it, it passed. But of course it did, because it's just checking that I got the API that I told iterator_interface to create, no? This just seems like needless repetition to me. I mean if I screwed it up to begin with, I'll screw it up in this macro too, no? But maybe I'm missing something obvious. (could be - it's getting late) > * Documentation? It's OK. I enjoyed some of the humor. :) It's missing some info for things that are customization points. For example base_reference() is shown in an example, but not really documented anywhere as far as I can tell. The tables aren't as useful/explanatory as one would hope. I mean I knew what they meant, but I'm not sure someone newer to this area would. (but then again, that's what blogs/articles are for I guess) I think it might also help if there were some explanation for what happens under-the-hood, in terms of what public methods get auto-generated from what, for which iterator types. For example, it's surprising that for a bidirectional iterator the user defines operator==(), but not for random-access iterator. (that particular case happens to be mentioned in a note, but you get my point) There are also typos and such, but I presume that gets checked later. > * Tests? Good. I copied them over and ran them as well. (but not the v2 tests, nor the ones for container_interface or view_interface) I think it would be better if there were some tests for iterator_interface with non-copyable value-types. Testing it only for `int`s is cheating. :) Also, random question: for the container_interface, did you try using it with the boost::fixed_string (or static_string, or whatever it's called)? I mean that _is_ a contiguous container, and it's in boost review too, so might it be a good test candidate? :) > * Usefulness? Very useful. iterator_facade/adaptor were showing their age. It's time for something new and shiny. I was happy that it reduced the number of functions we needed to implement in our current usages from 5 to 3. > - Did you attempt to use the library? Yup. I replaced three existing boost::iterator_facade usages in my company's code-base with this one, to try it out. Ran our unit tests with and without valgrind as well. But to be honest these weren't very complicated iterators. I did _not_ try replacing boost::iterator_adaptor, but I hope to try that eventually. > * Which compiler(s)? (old ones, so I could build my employer's codebase and run all their unit tests...) 1) gcc 7.3.1 with c++17 2) clang 5.0.0 with C++17, using gcc's libstdc++ Both using boost 1.55 (sorry!), with the stl_interfaces headers copied over manually, without using the CMake files in the github repo. Neither compiler has the early Concepts support. > * What was the experience? Any problems? Not really. The hardest part was figuring out the new model of what the derived had to define, compared to iterator_facade. (i.e., I was so used to the old model that it took me a bit to grok this one) > - How much effort did you put into your evaluation of the review? Only a few hours, maybe 4-5 total. Sorry, I wish I had more free time. :( > - Do you like the name container_interface? sequence_container_interface > is more precise, but seems a bit long. I'm not sure the length matters much for this use-case, as it's a one-time thing (generally), and not used by users of the actual container; and can anyway be aliased. (I mean, the "stl_interfaces" sub-namespace is annoying too, but it's not a big deal in my opinion) > - 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. Yes I think so, depending on what it did... but for *unordered* ones (i.e., hash-maps/sets), rather than rb-trees. I often find myself encapsulating them, and then having to write a lot of boilerplate public member functions. And several functions can be boiled down for hash-maps. For example count() and contains() can just use find(). I don't know why an unordered_container_interface wouldn't be do-able, including heterogenous lookups, for various hash-map/set flavors. (except, of course, that boost::unordered_map/set's API is different than std's for heterogeneous lookup; which is unfortunate) -hadriel

1 0

[review] [STLInterfaces] STLInterfaces iterator_interface mini mini review
by Arthur Gruzauskas 18 Dec '19

18 Dec '19

On Wednesday, 11 December 2019 11:21:23 AM AEDT Barrett Adair via Boost wrote: > 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 Arthur Gruzauskas > - Your knowledge of the problem domain I've written a number of iterator interfaces over the years. Nothing fancy, but have dipped my toes in iterator implementation. > - Whether you believe the library should be accepted into Boost (be clear > about this) ACCEPT, simply because I am using it happily. but I have only used container_interface, not the rest. > > In addition, you are strongly encouraged to answer the following questions: > - What is your evaluation of the library's > * Design? simple interface, small learning curve, great value for effort. A small number of methods to implement the essential concepts. A small enough concept chunk to be easily manageable. simple to use, just copied the code in the readme.md and adapted it. > * Implementation? worked for me. I didn't examine the code much. I like its layout and it looks clean to me. > * Documentation? The readme.md with that simple example was enough for me to adapt the intro sample iterator to my code. I note the example has been criticised by Gavin Lambert a few posts ago. But I love it as it made everything simple and clear. Reading the main doc page filled in a few conceptual gaps, but that readme.md gave me the overview that made the rest easy. > * Tests? So far brief tests have all worked well. I did not exhaustively test the iterators. They also worked fine in a couple STL algorithms. Again, I have only dealt with iterator_interface.hpp > * Usefulness? My experimental class would have stalled for some time if this easy iterator interface had not been there. Encouraged, I'm now looking at using it for more complicated structures. > - Did you attempt to use the library? If so: > * Which compiler(s)? clang-8 for c++17 on debian linux. > * What was the experience? Any problems? very straightforward. a few small glitches, as I just grabbed iterator_interface.hpp and fwd.hpp and made small changes for it to work inside my project. https://github.com/tzlaine/stl_interfaces/issues describes two minor issues, which could be well related to me just grabbing those 2 files only, outside the boost structure that would normally sustain it. > - How much effort did you put into your evaluation of the review? Several hours reading, adapting and getting it working for me. > > 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. It doesn't clash with anything in my mental namespace, so I'm happy with the name container_interface. BTW, I have not used container_interface, I just saw it now and had a look. I can see this simplifying some upcoming containers, and will certainly be giving it a go. view_interface is not something I have a need for currently. > - 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 > My one small concern is in the required method: constexpr auto operator-(repeated_chars_iterator other) const noexcept instead of: constexpr auto operator-(const repeated_chars_iterator& other) const noexcept I may soon have a need for an iterator that holds a lot of state, and copying that iterator for each subtraction makes me wonder about a performance penalty in inner loops. It is not a dealbreaker for this review, and I didn't examine Zach's tradeoffs for doing it this way. I see many of my use cases where this approach will be fine. This is my first review, incomplete as it is, mainly motivated because no one else has done one yet, and because I found iterator_interface useful and want to encourage Zach for this lovely simplifying interface. Thanks very much, Zach. Arthur

3 4

Unmerged change in boostcpp.jam
by Peter Dimov 17 Dec '19

17 Dec '19

boostcpp.jam on develop contains the following patch, which is not merged to master: diff --git a/boostcpp.jam b/boostcpp.jam index efc41c1ed..299401778 100644 --- a/boostcpp.jam +++ b/boostcpp.jam @@ -607,7 +607,7 @@ rule address-model ( ) return <conditional>@boostcpp.deduce-address-model ; } -local deducable-architectures = arm mips1 power sparc x86 combined ; +local deducable-architectures = arm mips1 power riscv s390x sparc x86 combined ; feature.feature deduced-architecture : $(deducable-architectures) : propagated optional composite hidden ; for a in $(deducable-architectures) { @@ -618,11 +618,13 @@ rule deduce-architecture ( properties * ) { local result ; local filtered = [ toolset-properties $(properties) ] ; - local names = arm mips1 power sparc x86 combined ; + local names = arm mips1 power riscv s390x sparc x86 combined ; local idx = [ configure.find-builds "default architecture" : $(filtered) : /boost/architecture//arm : /boost/architecture//mips1 : /boost/architecture//power + : /boost/architecture//riscv + : /boost/architecture//s390x : /boost/architecture//sparc : /boost/architecture//x86 : /boost/architecture//combined ] ; This seems to add support for "riscv" and "s390x" as architectures. Should this be merged to master?

1 0

Test Matrix not Updating
by Michael Caisse 16 Dec '19

16 Dec '19

We are aware that the test matrix has not been updating. The problem is caused by a server that we do not control. Things should be resolved in the next couple days. Thank you for your patience and sorry about the disruption. michael -- Michael Caisse Ciere Consulting ciere.com

1 0

Enabling warnings for library sources and tests but not for dependencies
by Alexander Grund 15 Dec '19

15 Dec '19

Hi, I want to build at least the tests but better also the library sources itself with warnings enabled and warnings-as-errors to avoid regressions. >From BoostAssert I found the following snipped added to the top of test/Jamfile.v2: project : requirements <warnings>pedantic <warnings-as-errors>on ; Further down I have a dependency on BoostFilesystem like: run test_stdio.cpp : : : <library>/boost/filesystem//boost_filesystem ; But now the build of BoostFilesystem fails: gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-5.4.0/release/cxxstd-11-iso/threading-multi/visibility-hidden/directory.o libs/filesystem/src/directory.cpp:217:48: error: unused parameter 'buffer' [-Werror=unused-parameter] Is there any way to restrict the warnings to my project only? Or at least the warnings-as-errors option? Is there a way to set warnings-as-errors via b2 command only for this library? This would avoid putting it in the Jamfile which could affect end-users, but having it on CI is actually enough. Alex

2 3

bug-fix release 1.72.1?
by Oliver Kowalke 15 Dec '19

15 Dec '19

Hello, unfortunately I accepted a faulty pull request and the commit that reverted it was not included into release 1.72 (for instance spawn() of Boost.Asio will fail to compile). Oliver

3 4

Assuming maintainership of boostorg/io
by Glen Fernandes 15 Dec '19

15 Dec '19

I'd like to take on maintainership of IO, as suggested by Peter. So far, I've already: * Implemented the Fundamentals TS v2 ostream_joiner as boost::io::ostream_joiner * Converted the documentation to Asciidoc * Updated the test cases to use Lightweight Test and build faster * Updated the CI configurations I also plan to: * Finish the boost::io::quoted implementation started by Beman but currently in detail. i.e. Update and improve the implementation. Add better documentation and more tests, and make it non-detail (public). * Migrate my boost::ostream_string facility from Boost.Utility (which is more general purpose) to Boost.IO (because, well, IO). * Make some minor improvements to the implementation of boost::io::ios_state. Glen

2 1

Re: [boost] Assuming maintainership of boostorg/io
by Bjorn Reese 14 Dec '19

14 Dec '19

On 2019-12-14 17:31, Glen Fernandes via Boost wrote: > I'd like to take on maintainership of IO, as suggested by Peter. +1

1 0

Attn: Maintainer of boost/bind.hpp
by Niall Douglas 13 Dec '19

13 Dec '19

In boost/bind.hpp there is injection of a boost namespace contents into the global namespace: ```c++ #include <boost/bind/bind.hpp> #ifndef BOOST_BIND_NO_PLACEHOLDERS #if defined(BOOST_CLANG) # pragma clang diagnostic push # if __has_warning("-Wheader-hygiene") # pragma clang diagnostic ignored "-Wheader-hygiene" # endif #endif using namespace boost::placeholders; #if defined(BOOST_CLANG) # pragma clang diagnostic pop #endif #endif // #ifndef BOOST_BIND_NO_PLACEHOLDERS ``` The fact that Boost actually disables the relevant compiler warning makes this particularly insidious. No modern C++ library should ever do "using namespace" into the global namespace in its public headers. Please fix this in the next release of Boost. Niall

2 4

Attn: Maintainers of Iterator, Python, ASIO, Detail, Core, Graph, QVM, Exception
by Niall Douglas 13 Dec '19

13 Dec '19

Dear maintainers of Iterator, Python, ASIO, Detail, Core, Graph, QVM, Exception, Please find attached a list of macros in your libraries without BOOST_ prefixing, as is required by Boost library guidelines. If you could fix these promptly, it would be appreciated. Niall

1 1

Re: [boost] [release] Boost 1.72.0 has been released
by Glen Fernandes 12 Dec '19

12 Dec '19

Andrey wrote: > In release notes, New Libraries says TODO. Also on the main page it showed a blank list of updated libraries. Both should be fixed now: https://github.com/boostorg/website/commit/3f37b654d7126c0ad312e50d227c03d2… https://github.com/boostorg/website/commit/7c897e8c768cf28113ba07488a6b5030… Glen

2 1

[release] 1.73.0 open for merging
by Marshall Clow 11 Dec '19

11 Dec '19

The master branch is open for merging all stable changes from develop, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging does not require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: https://github.com/boostorg/boost/wiki/Release-Schedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Boost Release Team

1 0

[release] Boost 1.72.0 has been released
by Marshall Clow 11 Dec '19

11 Dec '19

Release 1.72.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains new libraries and numerous enhancements and bug fixes for existing libraries. For details, including download links, see < http://www.boost.org/users/news/version_1.72.0> You can also download directly from: < https://dl.bintray.com/boostorg/release/1.72.0/> To install this release on your system, see < http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Marshall Clow, Michael Caisse

3 2

[release] Boost 1.72.0 Release Candidate 2
by Marshall Clow 10 Dec '19

10 Dec '19

The second release candidates for the 1.72.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.72.0/source/> The SHA256 checksums are as follows: 247a91dd7e4d9dd3c4b954b532fbc167ba62dc15ab834e5ad893d7c3f9eb5f0f ./boost_1_72_0_rc2.7z 59c9b274bc451cf91a9ba1dd2c7fdcaf5d60b1b3aa83f2c9fa143417cc660722 ./boost_1_72_0_rc2.tar.bz2 c66e88d5786f2ca4dbebb14e06b566fb642a1a6947ad8cc9091f9f445134143f ./boost_1_72_0_rc2.tar.gz 8c20440aaba21dd963c0f7149517445f50c62ce4eb689df2b5544cc89e6e621e ./boost_1_72_0_rc2.zip Changes since RC1: * A change to Boost.Proto that would cause compilation failures on the latest MS compiler. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Managers

2 4

Interest in a C++20 Unit Testing Framework?
by Krzysztof Jusiak 10 Dec '19

10 Dec '19

Hi, I was wondering whether there is any interest in exploring a C++20 single header/single module, macro-free Unit Testing Framework with no dependencies? Github: https://github.com/boost-experimental/ut Additional links: - Try it online: https://godbolt.org/z/uVDxkW - Benchmarks: https://github.com/boost-experimental/ut#benchmarks - How it works?: https://github.com/boost-experimental/ut#how-it-works Thanks, Kris

8 30

Re: [boost] [STLInterfaces] only three operations?
by Zach Laine 09 Dec '19

09 Dec '19

On Mon, Dec 9, 2019 at 12:55 PM Andrzej Krzemienski <akrzemi1(a)gmail.com> wrote: > > > pon., 9 gru 2019 o 17:32 Zach Laine <whatwasthataddress(a)gmail.com> > napisał(a): > >> >> >> >>> Same with the iterator in the flight map: >>> >>> >>>> https://github.com/tzlaine/flat_map/blob/master/implementation/flat_map#L266 >>>> >>> >>> According to C++17 requirements this shouldn't have been a >>> random_access_iterator. >>> >>> Also, std::ranges::sort() will not work with it. But this is not >>> directly related to `iterator_interface` >>> >> >> I don't know why you think that. ranges::sort() is designed to work with >> std::random_access_iterator, which is designed explicitly to support proxy >> iterators. Casey and Eric have assured me that this "just works". Do you >> know of a reason why it does not? If so, you've spotted a defect, and we >> should file an LWG issue immediately. >> > > Not sure if it is a defect. An iterator that returns a proxy as > ::reference can be a valid random_access_iterator. However, > std::ranges::sort(), apart from a random_access_iterator requirement, has > one more requirement: sortable<>: (http://eel.is/c++draft/sort) which > boils down to indirectly_writable ( > http://eel.is/c++draft/iterator.concept.writable) This last concepts > puts severe restrictions on proxy types. For instance you should be able to > assign to them when they are const-qualified. So a type like std::tuple<> > of references will not work. But you will be able to design a sufficiently > bizarre proxy type that will work with std::ranges::sort(), So in a way it > will work with *some* reference proxies. > Ok, I just realized this somehow drifted off-list. Re-adding the list... This is the definition of indirectly_writable: template<class Out, class T> concept indirectly_writable = requires(Out&& o, T&& t) { *o = std::forward<T>(t); // not required to be equality-preserving *std::forward<Out>(o) = std::forward<T>(t); // not required to be equality-preserving const_cast<const iter_reference_t<Out>&&>(*o) = std::forward<T>(t); // not required to be equality-preserving const_cast<const iter_reference_t<Out>&&>(*std::forward<Out>(o)) = std::forward<T>(t); // not required to be equality-preserving }; All you need to make this work is a reference type for which all those are well-formed. If you pick std::tuple, it all just works. If you pick std::pair, only the first two expressions in the requires expression work. You can easily define UDTs for which this concept works too, of course. Zach

1 0

Interest in an audio filtering / algorithm Library?
by Vinnie Falco 09 Dec '19

09 Dec '19

Is there any interest in having a new libraries for Boost that is focused on the audio domain (but with portions applicable generically)? I'm thinking about a library that does stuff like: * finite impulse response filtering * infinite impulse response filtering * time stretching, resampling * audio synthesis * audio algorithms * mixing * plenty of ready-to-run filters: - low pass, high pass, band pass - echo, reverb, flanger, phaser and the like This is a pure math library, no actual audio. To get an idea of the algorithms and use-cases check out my DSPFiltersDemo program (press Download Now): <https://github.com/vinniefalco/DSPFiltersDemo> Please note, my library is not what is being proposed, this would be a new library from a domain expert (not me). Thanks

7 8

[review][fixed_string] review period finishes today Dec 8
by Joaquin M López Muñoz 08 Dec '19

08 Dec '19

The review period of candidate Boost.FixedString finishes today, Dec 8. Many interesting subjects have been discussed about during these two weeks and I have quite a bit of material to digest before publishing the final review result plus further action points. I expect to be able to do so during the following week. Thank you to all the people who have contributed their reviews and comments and to Krystian and Vinnie for submitting their work and enduring the famously severe review ordeal. Best regards, Joaquín M López Muñoz Review manager for candidate Boost.FixedString

2 1

Re: [boost] Boost GIL
by Siddhartha Sen 08 Dec '19

08 Dec '19

Thanks a lot for forwarding my email to the boost GIL list. I will check it out. What I meant by conversion, however was primarily converting an image to negative and greyscale. As you may already know, the two pf them are pretty similar and OpenMP has shown how incredibly fast the process can be using more threads. I just feel GIL would benefit a lot from using parallel programming. On Sun, 8 Dec, 2019, 5:30 PM , <boost-request(a)lists.boost.org> wrote: > Send Boost mailing list submissions to > boost(a)lists.boost.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.boost.org/mailman/listinfo.cgi/boost > or, via email, send a message with subject or body 'help' to > boost-request(a)lists.boost.org > > You can reach the person managing the list at > boost-owner(a)lists.boost.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Boost digest..." > > > The boost archives may be found at: http://lists.boost.org/Archives/boost/ > > > Today's Topics: > > 1. Re: [fixed_string][review] Review of fixed_string (Rob Stewart) > 2. Re: Extending GIL (Mateusz Loskot) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 07 Dec 2019 13:23:51 -0500 > From: Rob Stewart <rstewart(a)ptd.net> > To: boost(a)lists.boost.org,Phil Endecott via Boost > <boost(a)lists.boost.org> > Cc: Phil Endecott <spam_from_boost_dev(a)chezphil.org> > Subject: Re: [boost] [fixed_string][review] Review of fixed_string > Message-ID: <142EED34-B802-4381-9FF9-C9FE999BA0F9(a)ptd.net> > Content-Type: text/plain; charset=utf-8 > > > > On December 5, 2019 9:35:35 AM EST, Phil Endecott via Boost < > boost(a)lists.boost.org> wrote: > > Peter Dimov wrote: > > > - a function that checks whether the remaining capacity is at least > > n should > > > be added. I suggest the name > > > > > > bool can_fit( std::size_t n ) const noexcept; > > > > > > although my previous choice of "has_capacity_for" has merit too. > > I suggest the simpler "fits". > > > Make this a free function template and you can use it with other > > containers: > > > > template <typename CONTAINER> > > bool can_fit( const CONTAINER& C, typename CONTAINER::size_type n ) > > noexcept > > { > > return C.capacity() - C.size() >= n; > > } > > That's a nice idea, especially with the name "fits". :) However, if you > reverse the parameters, "fits_in" would be a better name as it indicates > the argument order. > -- > Rob > > (Sent from my portable computation device.) > > > ------------------------------ > > Message: 2 > Date: Sun, 8 Dec 2019 01:25:04 +0100 > From: Mateusz Loskot <mateusz(a)loskot.net> > To: boost(a)lists.boost.org > Subject: Re: [boost] Extending GIL > Message-ID: > < > CABUeae_cupOMOhCNvvHaeruX2ksycHhVKkHJbtCSCLr-kW-XkA(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Sat, 7 Dec 2019 at 01:12, Siddhartha Sen via Boost > <boost(a)lists.boost.org> wrote: > > > > Having looked up this repository : > https://github.com/boost-gil/gil_threaded, > > I feel the idea was the same, but a lot of improvement can be made. > > Good, sounds like you may have a plan in mind > > > Also, there was no provision for image conversion, which I feel > > Please, you need to be more specific here. > What kind of conversion do you mean: color, channel/pixel type, format,...? > > p.s. I forwarded your post to the GIL mailing list > https://lists.boost.org/boost-gil/2019/12/0362.php > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > > ------------------------------ > > End of Boost Digest, Vol 6271, Issue 1 > ************************************** >

2 1

[release] 1.72.0 post-beta merges
by Michael Caisse 08 Dec '19

08 Dec '19

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See <https://github.com/boostorg/boost/wiki/Releases%3A-Beta-Merge-Policy>

11 31

[range] Trying to extend boost::range::combine to std::tuples
by Andres Llopis 08 Dec '19

08 Dec '19

Hi everyone, I am trying to make my own version of combine so that it works also with std::tuples. Someone on slack suggested that the zip iterator should be able to handle it properly. My attempt however fails when trying to use the metafunction tuple_of_references::type for the std::tuple of iterators. This is what I tried (https://godbolt.org/z/Ymjtvn) (Please excuse any style problems, this is my first post) namespace myns { using boost::iterators::zip_iterator; using boost::iterator_range; template<typename IterTuple> class combined_range : public iterator_range<zip_iterator<IterTuple> > { typedef iterator_range<zip_iterator<IterTuple> > base; public: combined_range(IterTuple first, IterTuple last) : base(first, last) { } }; template<typename... Ranges> auto combine(Ranges&&... rngs) -> combined_range<decltype(std::make_tuple(std::begin(rngs)...))> { return combined_range<decltype(std::make_tuple(std::begin(rngs)...))>( std::make_tuple(std::begin(rngs)...), std::make_tuple(std::end(rngs)...)); } }

3 5

Extending GIL
by Siddhartha Sen 08 Dec '19

08 Dec '19

Having looked up this repository : https://github.com/boost-gil/gil_threaded, I feel the idea was the same, but a lot of improvement can be made. For example, by using OpenMP, I feel the computational performance can be massively improved and that too, not requiring any extremely sophisticated hardware. Also, there was no provision for image conversion, which I feel is a very good extension. What do you all think?

2 1

[fixed_string][review] Review of fixed_string
by Peter Dimov 07 Dec '19

07 Dec '19

This is my review of FixedString. * Summary The library should be ACCEPTED. It's useful, for more than one domain, and specifically where compile-time string manipulation is concerned, everyone needs to reinvent it. The name fixed_string is fine as is. Alternatives exist, but I don't see any of them as unquestionably better, and one becomes accustomed to "fixed_string" after a very brief period. Throwing on exceeding capacity is fine as is. A function should be provided to check the remaining capacity, because writing this check by hand is very easy to get wrong, and in fact the library throughout its implementation consistently gets it wrong. * Documentation The documentation is adequate, but I don't find the reference convenient. I would prefer a synopsis that contains the entire class definition of `fixed_string`, so that I can see the various overloads at a glance. Instead, the synopsis only gives me the declaration of `fixed_string`, without even telling me what namespace it's in. (It also gives me `basic_string_view`, also without mentioning the namespace.) The current layout is fine if I want to look up a specific function by name. The format should ideally follow the standard library, with Throws and Expects clauses (the latter instead of "undefined behavior unless".) It's not documented when constructors and assignment operators throw. * Design - static_capacity should be removed; capacity() and max_size() should be static constexpr. - all nonthrowing functions should be marked `noexcept`. - initializer_list<CharT> overloads are of dubious utility. I know that the design copies std::string here, but I think that we should deviate and not provide them. - substr() should return a fixed_string, subview() a string_view (as already implemented.) - operator+ should be provided, only for arguments with capacity known at compile time (fixed_string<N>, CharT and CharT const (&)[ N ]), with the capacity of the result being the sum of the capacities of the arguments. This is not very useful for long strings, but it's fine for short strings, useful for compile-time manipulation, and useful in simple cases such as to_fixed_string( n ) + " bytes written". - a function that checks whether the remaining capacity is at least n should be added. I suggest the name bool can_fit( std::size_t n ) const noexcept; although my previous choice of "has_capacity_for" has merit too. This is, in my opinion, an absolutely necessary addition, because of my already-stated observation that the check is almost always gotten wrong. Here for instance is an example: if(size() + count > max_size()) BOOST_FIXED_STRING_THROW(std::length_error{ "size() + count > max_size()"}); The correct way to write it is max_size() - size() > count, which avoids the integer overflow in size() + count. In this case, passing count = (size_t)-1 will pass the check (when size() > 0) and then lead to undefined behavior. This makes the utility of reserve() dubious, because it basically invites one to get it wrong, but I think we should retain it for consistency. - everything should ideally be constexpr. The problem here is that constexpr requires initializing all elements, and this will heavily penalize runtime uses of f.ex. fixed_string<512>. On compilers with __builtin_is_constant_evaluated (gcc 9, clang 9) we should use that; otherwise, it might be worth it to create a specialization for N < some suitable upper limit. Again, any nontrivial string manipulation at compile time basically requires a fixed_string. * Implementation The physical separation of the library into three headers is inconvenient. A single header would make it possible to include the library directly on Godbolt via https, which is useful for both demonstrations and analysis of the generated code. In addition, hunting down the definitions is irritating for people reading the code. The reverse is true for the tests; they should be split into files each testing a logical group, such as constructors, assignment, append, and so on. The helper functions "testAS", "testI" and so on make reading the tests unnecessarily cryptic (and is quite annoying for reviewers.) They should have been named "test_assign", "test_insert". It's generally better to use `BOOST_TEST_EQ(s.size(), 0);` instead of `BOOST_TEST(s.size() == 0);` because the former prints the values on failure, which often gives clues as to where the error is. The test functions shouldn't be in the boost::fixed_string namespace. Users don't write their code in this namespace, so the tests don't test what users use. All capacity checks should be either audited for correctness and fixed, or use the proposed can_fit addition. Instead of repeating BOOST_FIXED_STRING_THROW(std::length_error{ "n > max_size()"}); in every function, which leads to it being inlined there repeatedly, this could use a helper function void throw_length_error( char const * msg, boost::source_location const& loc ) { boost::throw_exception( std::length_error( msg ), loc ); } taking advantage of the new boost::throw_exception overload that takes a source location as documented in https://www.boost.org/doc/libs/develop/libs/throw_exception/doc/html/throw_…. A variation could take `n` as an argument and compose a message containing it, f.ex. void throw_length_error_fmt( boost::source_location const& loc, char const * fmt, ... ); #define BOOST_FIXED_STRING_USE_BOOST should go, as already mentioned. Since the library requires C++11, there's no need to use BOOST_STATIC_ASSERT. static_assert is fine. Unless of course we backport it to C++03, which might be doable, although of questionable utility. Checking for overlap and using Traits::copy instead of Traits::move isn't needed. Traits::move does the same check anyway, so there's no gain, just an opportunity to get the check wrong and introduce undefined behavior. "The behavior is undefined if `count >= npos`" doesn't seem necessary. In this case, count will be bigger than max_size() and the constructor will throw std::legth_error. There's no reason to gratuitously introduce undefined behavior. All "undefined behavior" cases should consistently BOOST_ASSERT.

4 4

[nowide] Future
by Artyom Beilis 07 Dec '19

07 Dec '19

The nowide library was reviewed and accepted into Boost almost 3 years ago. I implemented most of fixes required under Review Fixed branch https://github.com/artyom-beilis/nowide/tree/reviewfixes Unfortunately I don't have any capacity to do maintenance for it on all various platforms: MSVC, mingw. cygwin etc mostly because virtually I don't develop on Windows and any time I need to go there I need to figure it out from the beginning (installations, environment, msvc) and I don't even have windows machine in my hands (all done in VM) I realized that I'm not windows developer any more and it would be impossible for me to complete the mission of maintaining the code mostly due to personal reasons and lack of development resources. I deeply regret wasting the time and effort of so many boost developers who invested to review. I understand that it is highly desired library but I just can get the job done I seek for your advice. Do I need to seek for an another maintainer or withdraw the library entirely? Once again sorry for disappointing the community and people who were invested in this library. Artyom Beilis

6 10

[review][fixed_string] End of review period approaching and a plea
by Joaquin M López Muñoz 06 Dec '19

06 Dec '19

The review period for candidate Boost.FixedString finishes tomorrow, Dec 4. There's an ongoing lively discussion on many aspects of the library, which is very good, but only three of you have cast your acceptance/rejection vote, which is not good. This is a gentle petition to the people engaging in the review who haven't voted yet: Vinícius, Nevin, Mike, Andrzej, JeanHeyd, Hans, Peter, Julien, Andrey, Tim, Gavin, Emil, (and anyone who might be still lurking) to please submit a review with an explicit vote. If you feel like you need some more time to do the work, I think we are in a position to extend the review period, but please express your intentions before I ask the review wizards. Thank you! Joaquín M López Muñoz Review manager for candidate Boost.FixedString

13 35

[release] Boost 1.72.0 Release Candidate 1
by Marshall Clow 05 Dec '19

05 Dec '19

The first release candidates for the 1.72.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.72.0/source/> The SHA256 checksums are as follows: fcd8b598bc63ae7bbd3e72635d95b9d749ef65f4e5342c24445ea1fb9d417ac3 boost_1_72_0_b1_rc1.7z f6a527a261e273bfd2b6161d359ab9fb53c1795239c696f501a62f575cd30bda boost_1_72_0_b1_rc1.tar.bz2 8e591146d39e8cb45c74540aae26ae6321b1e83ab1b12e236dd117f93475ceb9 boost_1_72_0_b1_rc1.tar.gz 3425e7bfd49a6ad70aa7e82c1c740f7821eb58d14604b133be4dfbcdc0c58e3a boost_1_72_0_b1_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Managers

3 10

[review][fixed_string] Andrzej's feedback
by Andrzej Krzemienski 05 Dec '19

05 Dec '19

Hi Everyone, This can hardly be called a review, as I didn't look thoroughly at the implementation. (I only checked what happens on the resize() over the capacity(), as this was not clear from the docs.) I think that ultimately the library would be a useful addition to Boost, however I would not like to rush it before its design is fully baked, and my impression is that it isn't yet. Therefore my recommendation would be to REJECT the library at this point, and encourage the authors to resubmit it for the second review once the design goals and design decisions have been clearly settled and communicated. My vision of a review is that we: 1. First evaluate the design goals, whether they are worth pursuing 2. Then we evaluate the design *against* those goals. 3. Then we evaluate the documentation and implementation *against* the design and goals. I cannot even go to #3, as to me #1 is missing some parts. There are different possible goals: 1. Treat this new string as many other STL sequence containers with variable size. In particular, users use it as if its max_size() were infinite, and are prepared that at some point an exception might be thrown. 2. Treat it as a "drop-in replacement" for std::string with no-heap-alloc guarantee. 3. Make something suitable for embedded systems where the user provides the guarantee: "I will never make the size() of this string go above this value. If I did, it would be plain clear that the program is not doing what it was supposed to." These goal 3 is in clear conflict with either 1 or 2. This becomes clear when we consider what should be the response to doing a resize() over capacity(): a precondition violation or a normal course of action signaled by an exception. The authors should make a choice which of these goals is not supported and communicate it clearly from the outset in the docs. I think this decision has already been made: the library was extracted from Boost.Beast and there the purpose must have been clear. It is just that it is not communicated in fixed_string library. Any decision is good. In C++ performance trade-offs are part of the contract (interface), so there is room in Boost for many strings: small strings, short codes, fixed size strings, fixed capacity strings. But for each library it should be clear what trade-offs were chosen and why. We have a situation that there exists static_vactor in Boost, which defines the resize() over capacity() to be a precondition violation. And fixed_string needs to provide some response to this fact: why did you choose a different design? I consider the choice of name to be part of the design: you cannot assign the name before you have decided on the goals. "static_string" might be a good name if you chose the same trade-offs as static_vector. But if you make different trade-offs, it might be better to use a different name. Making a resize() over capacity() a precondition violation is a *feature* useful for bug detection and I do not consider it a valid argument that "library will throw exceptions and if you never resize() over capacity() you will never see exceptions or std::abort()". If this is a precondition, then I expect of a library to put some BOOST_ASSERT() or _builtin_unreachable() in those paths to enable better bug detection. I find the goal "a drop-in replacement for std::string" invalid. You surely mean only a drop in replacement for some subset of usages. I guess this subset comes from the usage in Beast, and I would expect that it is clearly outlined what this subset is. One of the operations on strings that I use most often is operator+, so when I hear that this operation is not implemented in a class that claims to be a drop-in replacement for string, I see a contradiction. There might be valid reasons not to provide operator+, but the documentation cannot state that this is a drop-in replacement for std::string. I think that only after the above issues have been sorted out can we have a review of the implementation and the documentation. One remark about documentation is that I was not able to find what `resize()` over `capacity()` does. This is the most important information that I was after. anything else is more less intuitively clear from the analogy to std::string. I hope that this feedback doesn't sound discouraging. I appreciate the work Krystian and Vinnie have put into making this submission, and I would like to see this library ultimately included in Boost. Regards, &rzej;

7 27