- Boost - lists.preview.boost.org

[outcome] Major changes for Boost 1.72 release
by Niall Douglas 11 Oct '19

11 Oct '19

Just as a heads up to those who care, and any pretesting of these changes in advance of the Boost release is welcome. There are two breaking changes: 1. The git submodule mechanism used by standalone Outcome of specifying dependent libraries has been replaced with a cmake superbuild of dependencies mechanism instead. Upon cmake configure, an internal copy of quickcpplib will be git cloned, built and installed into the build directory from where an internal `find_package()` uses it. This breaks the use of the unconfigured Outcome repo as an implementation of Outcome, one must now do one of: 1. Add Outcome as subdirectory to cmake build 2. Use cmake superbuild (i.e. `ExternalProject_Add()`) to build and install Outcome into a local installation. 3. Use one of the single header editions. 2. For standalone Outcome, the current compiler is now checked for whether it will compile code containing C++ Concepts, and if it does, all cmake consumers of Outcome will enable C++ Concepts. Set the cmake variable `CXX_CONCEPTS_FLAGS` to an empty string to prevent auto detection and enabling of C++ Concepts support occurring. There are two new features: - Standalone outcome is now `make install`-able, and cmake `find_package()` can find it. Note that you must separately install and `find_package()` Outcome's dependency, quickcpplib, else `find_package()` of Outcome will fail. - Support for C++ Coroutines has been added. This comes in two parts, firstly there is now an `OUTCOME_CO_TRY()` operation suitable for performing the `TRY` operation from within a C++ Coroutine. Secondly, in the header `outcome/coroutine_support.hpp` there are implementations of `eager<OutcomeType>` and `lazy<OutcomeType>` which let you more naturally and efficiently use `basic_result` or `basic_outcome` from within C++ Coroutines -- specifically, if the result or outcome will construct from an exception pointer, exceptions thrown in the coroutine return an errored or excepted result with the thrown exception instead of throwing the exception through the coroutine machinery (which in current compilers, has a high likelihood of blowing up the program). Both `eager<T>` and `lazy<T>` can accept any `T` as well. Both have been tested and found working on VS2019 and clang 9. More detail can be found at: https://boostorg.github.io/outcome/changelog.html Niall

3 4

Seeing spam designation in message title
by Edward Diener 10 Oct '19

10 Oct '19

The previous message I sent to this mailing list shows the word [SPAM] in the title to the message. Does anybody know why this happened ? I am obviously not a spammer being the author of two libraries and maintainer of another.

3 3

Regression tests on 'develop'
by Edward Diener 10 Oct '19

10 Oct '19

It looks like on the 'develop' side most regression tests are either not being run very often or there is some problem in the posting of the latest results. I suspect the former but I thought it should at least be brought up. On the 'master' side many more recent recent regression tests are showing.

1 0

A solution to return dynamic strings without heap allocation. Any interest?
by Roberto Hinz 09 Oct '19

09 Oct '19

Hi all, I haven't been succesful at attracting interest in a formatting library [1] I've been working lately. But recently I realized that part of it could be isolated as a small standalone library that could solve an old common troublesome situation in C++: Suppose you need to create a function that returns/provides a string whose content and size is unknown at compilation time. The first approach is to make it return a `std::string`. But if it need to be usable in environments like bare-metal real-time system, then one usually makes it take a raw string as an output argument, more or less like this: struct result{ char* it; bool truncated; }; result get_message(char* dest, std::size_t dest_len); But this is clearly not a perfect solution since there's nothing really effective the caller can do when get_mesage fails because of the destination string being is too small. So I present the `outbut` abstract class. It somehow resembles `std::streambuf`, but with a simpler and lower level design, which is the result of many attempts looking for the best performance [2] and usability in my formatting library. Afaics, it does not require a hosted C++ implementation, though I would like someone else to confirm that. Now the caller of `get_message` has to choose or create a suitable class type deriving from outbuf, that dictates where the message is written to. For example, if the user wants to get a `std::string`, then `string_maker` will do the job: #include <boost/outbuf/string.hpp> // ... boost::outbuf::string_maker<false> msg; get_message(msg) std::string str = msg.finish(); Or, if one wants it to write into a raw string, then use `cstr_writer` char buff[buff_size]; boost::outbuf::cstr_writer csw(buff, buff_size); get_message(csw); auto result = csw.finish(); if (result.truncated) { // ... Those `finish` functions above do not belong to `outbuf`. They are defined in the concrete derived types only. It's solely by convention that they share the same name. Yes, using `string_maker` still leads to heap allocation and `cstr_writer` to string truncation. The problem isn't solved by these. However, a string object is never the final destination. So the user could rather use another class that writes the message directly into the final destination ( output console, a log file, an LCD display or whatever ). It is not difficult to implement concrete subtypes of `outbuf`. `outbuf` is actually a type alias: template <bool NoExcept, typename CharT> class basic_outbuf; using outbuf = basic_outbuf<false, char>; using outbuf_noexcept = basic_outbuf<true, char>; That `NoExcept` template parameter is perhaps the controversial part. It is not present originally in my formatting library. Besides the destructor, `basic_outbuf` has only one virtual function: `recycle()`, and it is declared as `noexcept(NoExcept)`. This is the only effect the `NoExcept` template parameter has. All other functions are guaranteed not to throw. Hence, by taking a `outbuf_noexcept&` parameter, a function states that the destination must not throw. That might be particularly good if such object comes from another module and we must avoid exceptions crossing modules boundaries. On the other hand, if a function takes an `outbuf&`, then it also accepts `outbuf_noexcept&`, because `basic_outbuf<true, CharT>&` derives from `basic_outbuf<false, CharT>`. When using `string_maker` you can choose between the two kinds. `string_maker<true>` derives from `basic_outbuf<true, char>&`. So if any exception raises from its internal `std::string`, then it is caught by a try/catch(...) block, stored as an `exception_ptr` and rethrown by `finish()`. This has the undesirable effect of delaying its proper handling ( after all, we rather stop what's being doing as soon as possible when an error appears ). So I think the recommendation would be to use `string_maker<false>&` if possible, and `string_maker<true>&` only if necessary. The reason why I think it's controversial is that it makes `recycle()` violates the Lakos Rule. And although the Lakos Rule is not a requirement in boost (afaik), I was wondering whether this library could interest LEWG in future as well. Anyway, this whole noexcept idea is not a central part of this library and can it be removed. Now, the other topic is how to implement that `get_message` function, i.e., how to write into an `outbuf` object. One can use `puts` and `putc` functions to insert string and chars. One can also use `fmtlib` through an output iterator adapter. Or one can write directly in the buffer. But I will ask you to read the doc [3] for that. It's a quick read, quicker than this email. The repository is: https://github.com/robhz786/outbuf I would prefer it to be part of Boost.Core instead of being a standalone library, and also to remove the `outbuf` namespace. But that is up to you. Best regards, Roberto [1] The Stringify library: https://github.com/robhz786/stringify [2] The great performance of Stringify is mainly thanks to the design of outbuf ( named there as `output_buffer` ): https://robhz786.github.io/stringify/doc/html/benchmarks/benchmarks.html#be… [3] "Writing into and outbuf object" https://robhz786.github.io/outbuf/doc/html/index.html#boost_outbuf.overview…

5 13

[Boost.MSM] Please, update master with changes from develop
by Deniz Bahadir 08 Oct '19

08 Oct '19

Hello world, I just stumbled across a compilation-error with the latest Boost release (1.71) of Boost.MSM for which I already provided a merge-request [1] a year ago, and which was merged to "develop" branch at that time, too. Still, the "master" branch lags this merge-request (and a lot more [2] from former years which are in "develop") but has some other unrelated merge-requests [3] merged in which are not in "develop". I would love seeing "develop" being merged into "master" (and maybe vise-versa) so that bugs for which fixes already exist will no longer be present in the next Boost release. Thanks for taking care of. Deniz [1] https://github.com/boostorg/msm/pull/15 [2] https://github.com/boostorg/msm/compare/master...develop [3] https://github.com/boostorg/msm/compare/develop...master

3 2

[contract] new maintenance release for Boost 1.72
by Lorenzo Caminiti 07 Oct '19

07 Oct '19

Hello Release Managers & all, I made a maintenance release of Boost.Contract. All tests pass, docs are updated, etc. The code is up-to-date in boost/contract/master. Can you please pull changes from boost/contract/master into the upcoming Boost 1.72 release? These are the changes: * Using std::uncaught_exceptions on C++17 compilers onward (instead of the now obsolete std::uncaught_exception). * Fixed a few warnings. * Removed linking to Boost.System (Boost.System is now a header-only library). * Added this library to Boost's Continuous Integration (CI). * Fixed documentation typos. Thank you in advance. --Lorenzo

2 2

git pull on Boost 'develop' branch problem
by Edward Diener 03 Oct '19

03 Oct '19

When I do a 'git pull' on Boost checked out to 'develop' it ends with: error: Server does not allow request for unadvertised object 3eb4826d1d2a3e46207a7e4a0467d9bab96d37f5 Anybody know why this is happening with the latest Boost in the 'develop' branch and if I need to do something to correct this ? It does not seem to b3e affecting anything, and it appears the 'git pull' is successful at the top level in pulling the latest 'develop' changes.

4 3

Re: [boost] New JSON library from the maker of Beast!
by Bjorn Reese 30 Sep '19

30 Sep '19

On 9/30/19 12:14 PM, julien.blanc(a)tgcm.eu wrote: > Do you have an example of an efficient implementation of a pull parser on top of async io ? I find push parsers really more straightforward in that case. Vinicius has an HTTP pull parser here: https://github.com/BoostGSoC14/boost.http > Pull parsers can also be built on top of push parsers, although it is less easy. Indeed, that is how we implemented XmlTextReader in libxml2, and it was a rather painful experience. Coroutines can help, as Phil pointed out, but pull parser are also a natural fit for parser combinators (e.g. HTTP contains a partial URL syntax, so it could be created combining HTTP and URL pull parsers.) I am not sure how well coroutines would handle this case.

1 0

Who is maintaining Boost.Random?
by Christoph Conrads 29 Sep '19

29 Sep '19

Last Tuesday I submitted a feature request for Boost.Random and received absolutely no feedback which seems to be unusual judging by last week's discussions (e.g. secure-by-default networking with Boost.Asio). Is anybody maintaining Boost.Random currently and if not, how can I proceed with my feature request? Christoph Conrads

2 3

How to handle contributions from anonymous?
by Hans Dembinski 27 Sep '19

27 Sep '19

Hi all, I got a PR from a contributor who prefers to remain anonymous. The person created new files and instead of putting a real name, the person added just initials. I am talking to the person to see whether they can be convinced to give a real name. Any advice on how to handle this? My feeling is that a copyright notice without a real name is illegal. I could publish the code in my name, but then a documented transfer of copyright from the contributor to me is missing, which then puts me in a vulnerable position. Any thoughts? Best regards, Hans

5 6