- Boost - lists.preview.boost.org

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

iostreams gzip_compressor
by Kemin Zhou 05 Dec '19

05 Dec '19

I have been using the compressor and decompressor for a while now. One of the issues is the performance not sufficient for large data operations. The underlying zlib library is single-threaded, and there is a parallel version implementation at application level https://zlib.net/pigz/ pigz. When working with large file compression and decompression it usually take 8 hours to do the job. If I can use multi-threaded version then it usually can be done within one hour. There is a strong need to use multi-threading to speed up this process for me. I would appreciate that someone can implement this feature. If not I can work on this project. Not sure what's the best way to go about this. -- Kemin Zhou 858 366 8260

1 0

[fixed_string] Copying/comparing entire strucutre
by Phil Endecott 05 Dec '19

05 Dec '19

Dear All, Considering small-capacity fixed_strings like the example that I gave previously: struct NameAndAddress { static_string<14> firstname; static_string<14> surname; static_string<30> address_line_1; static_string<22> city; static_string<10> postcode; }; I have been looking at how best to copy and compare them. For small-capacity strings, and also for large-capacity strings when their size approaches the capacity, it will be quicker to unconditionally copy/compare everything, including the unused bytes beyond the end, rather than looping over just the current size. I've tried a very crude benchmark based on this: struct string { uint8_t size; std::array<char,N> data; }; extern void copy_all(string& dest, const string& src) { dest = src; } extern void copy_size(string& dest, const string& src) { dest.size = src.size; std::copy(src.data.begin(), src.data.begin()+src.size, dest.data.begin()); } Results will depend on the architecture but I found that for N < 64 it was probably always best to copy_all(). For N==255, time for copy_all() and copy_size() is about equal when the container is half full. Things are more complicated for operator== because of the unused bytes. It would be necessary to initialise everything to 0 and maintain that during e.g. erase() and assign(). I haven't tried to benchmark that but I suspect the trade-off would be similar. operator< is a mess due to endianness. I don't know whether any compilers or memcmp() implementations are smart enough to use byte-swap instructions to process data 4 or 8 bytes at a time. I don't think I'm suggesting that this should necessarily be implemented in fixed_string, at least not without lots more investigation, but it does illustrate more of the trade-offs that exist between different applications. Regards, Phil.

2 1

[ Review ] [ fixed_string ] Accept
by JeanHeyd Meneide 05 Dec '19

05 Dec '19

Dear Boost, This is a review of boost.fixed_string. It is my first review, so take it with a grain silo's worth of salt. ------------- Summary 📝 -------------- Accept fixed_string. It's about ---------------- What I Did ⚙️ ---------------- - I ran its tests, VS 2019 i686 and x86-64 | VS 2017 i686 and x86-64 | MinGW 9.2.0 i686 and x86-64 - I put it inside itsy.bitsy (https://github.com/ThePhD/itsy_bitsy) and used it as an underlying container in its tests. - I put it inside my private text repository as an underlying container to hold code units for several different encoding schemes and it work (https://github.com/ThePhD/text-dev | far-behind implementation at https://github.com/ThePhD/text) - I generally messed around with it in a basic main.cpp file and read the docstrings and docs while comparing it to cppreference. -------------- Strengths 💪 -------------- +1 - Follows std::string's container design nicely, making it easy to program around and know what to expect from the outset. (Side note: ignore whoever said to remove the initializer list ones: I used all of them. It's necessary to be considered a SequenceContainer (https://en.cppreference.com/w/cpp/named_req/SequenceContainer).) +1 - Works with all character types. char, wchar_t, char16_t, char32_t, and -- in C++20 mode -- char8_t for the compilers that have it. +1 - insert, erase, clear, push_back, push_front meet specification I flexed it by inserting it as part of itsy.bitsy's tests and using it as one of its sequence containers. +1 - docs are straightforward. +1 - iterators work just fine. I tested it using itsy.bitsy as an underlying container for a reference_wrap'd bit_view as well as a stress testing it under my phd::text implementation. It worked fine as an underlying container for UTF8, UTF16. UTF32, and UTF-7-EBCDIC storage. +5000 - Standalone. I wish more Boost libraries were packed this way. I can make it not depend on Boost as a whole; great for dropping into random codebases and using as a replacement. Also compiles faster for those of us who have C++17+ capable compilers. ------------------- Weaknesses 🤒 ------------------- -1 - Naming. fixed_string<500> works, wfixed_string<500> doesn't, basic_fixed_string<char, 5000> doesn't either. It uses a different naming scheme from the standard, and led me around in circles on first use until I forced myself to read the template head of the class declaration. But it's Boost, so we can afford to be different and stuff. Just don't do static_vector. :D -0 - operator+ I wanted it. It wasn't there. I can see why, since you would have to pessimistically expand the size to the max between the two. Do enough additions and you can explode the final result's stack size several, so this isn't really a loss. Besides,-0 is just 0 on any reasonable 2's complement machine. -0 - noexcept It's 2019, everyone's getting on the noexcept train. Don't let it leave you behind! -2500 - Constexpr is lacking. I could not compile any of itsy.bitsy's constexpr, compile-time, or static_assert tests. I could not compile any of the static_assert tests from latest private text development. This prevents a wide range of applications, including my failure to substitute boost.fixed_string for Hana's Fixed String implementation in CTRE and failure to use fixed_string as a compile-time buffer for encoded and decoded text. -------------- Misc. -------------- - I see you added subview, very nice. 👏 - substr should continue to return a fixed_string. - The empty optimization and size optimization is important. Don't listen to anyone who tells you fixed_string<0> should report false for std::is_empty_v<fixed_string<0>>. I spend LITERALLY MILLIONS OF YEARS (definitely literally) programming special __ebco<T, tag> or slapping [[no_unique_address]] on things to cut down on memory sizes. Please don't cause a cascade of bloated size with MSVC's current crappy base class """optimization""" rules (the new, better ones are still opt-in because yay, ABI breaks). The closer things are to being small enough or trivial enough that they get register-passed, the better. - Speaking of the size optimization, MSVC's standard string also employs a trick where they shove the size in the last CharT. May be of use to you here, but probably not worth the efforts. -------------- Unrelated -------------- The following is boring things not related to the review but stated here for extra flavor that can be completely ignored: - Boy that CMake file hurts my feelings. I fixed it up so I could use it with add_subdirectory. It promised me an easy integration and smacked me upside the head instead. But at least I could get the tests going soon enough. Maybe don't commit it, it gives the impression it's for public consumption (it's not). - Tests are slightly inscrutable, better names would be nice. - For constexpr: use a union of { char derp; CharT value; } and value-initialize the char. Provide iterators that walk over the union and on deref directly handle you the CharT& lvalue reference. .data() is unimplementable as constexpr like this but who cares: you have a constexpr begin() and that's what people should be using. .data() is for type-punning shenanigans. - You should turn up the warnings on MSVC: there's a few places where there's an implicit narrowing thanks to going from size_type (std::size_t) to smallest_width_t and MSVC gives a snippy warning. Overall, yay! Try to get the constexpr stuff in quick; that's what's going to make this library interesting to use for C++20 and beyond, and have Boost libraries start being things to look forward to, rather than representing the Old, Boring Establishment that I reach for when I hear the words "Sea Plus Plus Oh Three". Great Job, JeanHeyd Meneide

3 3