- Boost-announce - lists.preview.boost.org

[review] [STLInterfaces] review extended until 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

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

15 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

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

1 0

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

11 Dec '19

The formal review of Zach Laine's STLInterfaces library begins now, and will run through December 19. To submit a review, please see the corresponding thread in the boost dev list.

1 0

[review][fixed_string] FixedString review starts today
by Joaquin M López Muñoz 24 Nov '19

24 Nov '19

The Boost formal review of Krystian Stasiowski and Vinnie Falco's FixedString library starts today November 25 and extends up to December 4. Description FixedString provides a dynamically resizable string of characters with compile-time fixed capacity and contiguous embedded storage in which the characters are placed within the string object itself. Its API closely resembles that of std::string. Repo and docs GitHub repository: https://github.com/18/fixed_string Online docs: https://18.github.io/doc/fixed_string Review questions Here are some questions you might want to answer in your review: - 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 what compiler? 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? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? I invite you to submit your review, either publicly to the developers or the users lists, or else, if for whatever reason you don't want to go public, directly to me. Thank you for investing your time on reviewing Krystian and Vinnie's work and for contributing to the advancement of Boost. Best regards, Joaquín M López Muñoz Review manager for candidate Boost.FixedString

1 0

[review] [STLInterfaces] STLInterfaces review starts December 10
by Barrett Adair 23 Nov '19

23 Nov '19

The Boost formal review of Zach Laine's STLInterfaces library will take place December 10 - 19, 2019. Please consider participating in this review. The success of Boost depends on our robust library review process. 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 Code: https://github.com/tzlaine/stl_interfaces Docs: https://tzlaine.github.io/stl_interfaces/doc/html/index.html Thanks, Barrett Adair

1 0

Interest in a C++20 Unit Testing Framework?
by Krzysztof Jusiak 21 Nov '19

21 Nov '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

1 0

Re: [Boost-announce] [Boost-users] Interest in a Unicode library for Boost?
by Zach Laine 30 Oct '19

30 Oct '19

On Wed, Oct 30, 2019 at 7:59 AM Klaim - Joël Lamotte <mjklaim(a)gmail.com> wrote: > > > On Sat, 26 Oct 2019 at 03:11, Zach Laine via Boost-users < > boost-users(a)lists.boost.org> wrote: > >> About 14 months ago I posted the same thing. There was significant work >> that needed to be done to Boost.Text (the proposed library), and I was a >> bit burned out. >> >> Now I've managed to make the necessary changes, and I feel the library is >> ready for review, if there is interest. >> >> This library, in part, is something I want to standardize. >> >> [snip] >> >> >> > (as a power user) > I would be interested to have such library in Boost and already had plan > to try Boost.Text in my next C++ project with text. > > I am following the discussions happening in SG16 and understand that there > are some differences with the parts that will be proposed for > standardisation (as ThePHD explains in his talk). > Though honestly both approaches seems to solve my problems so I'm open to > trying both. If boost.text is stable today, I'm happy to use it (at least > to replace ICU and have a proper unicode text type). > Yes, JeanHeyd and I started with very different approaches, but we're converging somewhat. Zach

1 0

Interest in a Unicode library for Boost?
by Zach Laine 26 Oct '19

26 Oct '19

About 14 months ago I posted the same thing. There was significant work that needed to be done to Boost.Text (the proposed library), and I was a bit burned out. Now I've managed to make the necessary changes, and I feel the library is ready for review, if there is interest. This library, in part, is something I want to standardize. It started as a better string library for namespace "std2", with minimal Unicode support. Though "std2" will almost certainly never happen now, those string types are still in there, and the library has grown to also include all the Unicode features most users will ever need. Github: https://github.com/tzlaine/text Online docs: https://tzlaine.github.io/text If you care about portable Unicode support, or even addressing the embarrassment of being the only major production language with next to no Unicode support, please have a look and provide feedback. I gave a talk about this at C++Now in May 2018, and now it's a bit out of date, as the library was not then finished. It's three hours, so, y'know, maybe skip it. For completeness' sake: https://www.youtube.com/watch?v=944GjKxwMBo&index=7&list=PL_AKIMJc4roVSbTTf… https://www.youtube.com/watch?v=GJ2xMAqCZL8&list=PL_AKIMJc4roVSbTTfHReQTl1d… Zach

1 0

Result of out_ptr review.
by Zach Laine 29 Jul '19

29 Jul '19

I've compiled the results of the reviews of out_ptr during its recent review. Unfortunately, out_ptr is NOT ACCEPTED, though many of the reviewers indicated interest in seeing it come back in some future form. I counted these formal reviews: Andrey Semashev: reject Louis Dionne: accept David Sankel: reject Phil Endecott: reject Glen Fernandes: reject Gavin Lambert: reject Thanks to all of the above reviewers, and to all those who contributed to the ongoing discussions surrounding out_ptr, even if they did not have time for a full review. Points against out_ptr raised during the review: - Many reviewers indicated their puzzlement that this library was proposed at all, since they had never seen enough calls to C APIs in their own code to motivate the need for out_ptr. - Some reviewers who did find the motivating cases of the library compelling, still said that they would prefer to write wrappers instead of using something like out_ptr. - Multiple reviewers want the library to provide error-reporting help (it currently does not). In particular, for c_func(out_ptr(p)), there was a concern about whether p is assigned a value, when c_func() returns a failure-status. - There was concern from several reviewers about the fact that out_ptr's types' dtors may throw, though this is only limited to the use of out_ptr with shared_ptr and similar smart pointers. In particular, non-unique_ptr uses will never throw in out_ptr's types' dtors, unless the user provides a throwing deleter. - Multiple reviewers disagreed with the use of template specialization as a customization mechanism. - There was widespread concern about the use of potentially UB-invoking tricks to get max performance out of the implementation. - Many reviewers wanted a more typical Boost tutorial introduction in the documentation. Now please permit me a digression. The library attempts to take a call that looks like this (simplest call possible): // CASE 0 foo * new_foo; TODO if (!create_foo(&new_foo)) { // etc. ... } And turn it into something as close as possible to this: // CASE 1 std::unique_ptr<foo> new_foo; if (!create_foo(new_foo)) { // etc. ... } out_ptr does a great job of this lexically: // CASE 2 std::unique_ptr<foo> new_foo; if (!create_foo(out_ptr(new_foo))) { // etc. ... } If you have not written thousands of lines of code that look like case 0, stop for a second and consider what it would be like to drop those thousands of raw pointers into your code, and how much you would like to replace them all with unique_ptrs. Now consider what it would take you to write all the wrapping functions necessary to make those thousands of calls look like case 1. You may make tooling to generate the wrappers, and that's time consuming. Writing it by hand is even more so. out_ptr also has the nice property that using it as I have above with unique_ptr does not change the meaning of the code, except to ensure that new_foo is guaranteed to be treated in a RAII manner. Thus we get increased exception safety, memory leak mitigation, etc. -- y'know, all that RAII stuff. If out_ptr is implemented well, case 2 should produce nearly identical object code to case 0, except that case 2 handles calling new_foo's dtor at the right time. Note that because of this, you have the same relationship to the C API in all three cases. That is, you need to check for the success value returned from create_foo(), and you need to know what create_foo()'s contract is in the face of errors -- did it write to new_foo or not? out_ptr is how you get from raw pointers to RAII ones, not how you solve all programming problems related to calling functions. Hopefully that motivates the use case for out_ptr, even if you don't need it in your own code. Hopefully that also allays concerns that out_ptr is not doing enough -- doing more is outside the library's scope. Now, on to exceptions in out_ptr's types' dtors. I heard a lot of discussion about this during the review. To me, concerns about what happens when an out_ptr or an inout_ptr throws in its dtor misses the point entirely, because it is concerned with fixing corner cases we should not even care to support. Instead of worrying about the semantics of exceptions in those kinds of situations, we should instead be asking why we want to support user code like this: ... } catch { create_foo(in_out_ptr(my_shared_ptr_to_a_foo)); ... } In other words, we don't really care about the dtor exceptions, unless: - there is an active exception already, and - we are also calling a C API to create a new object (a possible, but certainly atypical thing to do when handling an exception), and - we're catching this new object in a shared_ptr-like smart pointer that might throw on construction. Who writes code like that? Few people, perhaps none. It's not impossible to see code like that, but until there are well-motivated cases for this, maybe leave it for a later version of the library. In other words, the question should have been "Why support anything other than nothrow-constructible RAII types like unque_ptr?" Note that I find this argument compelling for the WG21-facing version of this work too. To summarize: I think the first four bullet points listed at the beginning of this post are, or could easily be made to be, irrelevant. So, that leaves some issues still outstanding: - figure out how to provide customization points (I'm actually fine with the current approach...), - eliminate the UB-dangerous code, or make it opt-in, - rework the tutorial portion of the docs, and - many assorted doc cleanups. That does not seem like an unreasonable amount of stuff to resolve in post-review acceptance readiness. I bring all this up because I do in fact hope that JeanHeyd brings this back for a future review, and I hope that my arguments here will convince some of you that this library is a useful thing to have around. I waited until now to say any of these things in an attempt to remain impartial during the review; I've been bothered by seeing previous review managers clearly represent a pro-acceptance position from the start. Thanks to JeanHeyd for his submission. A no-vote from this group is a tough thing, and I hope that the feedback he has received takes some of the sting out. Zach

1 0