- Boost - lists.preview.boost.org

New Website Repositories
by Vinnie Falco 16 Feb '24

16 Feb '24

All: The contribution of a brand new, mostly complete website at the level of quality of what we at The C++ Alliance have developed (see https://preview.boost.org) is a rare event. We are proud to share this special moment in Boost history. As is the Boost tradition we propose to do the following: * Transfer of all website related repositories to the Boost GitHub organization (these will also be renamed to something sensible): https://github.com/cppalliance/temp-site https://github.com/cppalliance/temp-site-documentation https://github.com/cppalliance/site-docs https://github.com/cppalliance/boost-mailman ...plus any other miscellaneous necessary repositories that Sam has created for the administration of the website, mailing list, and release process. * Whatever is the appropriate license for the artwork to be used on the website, with copyright to "The C++ Alliance, Inc. (https://cppalliance.org)" With respect to the artwork licensing, I have to admit I am not an expert so we will work to find out what the proper solution is. Thanks

3 3

Slack Workspace Link
by Spencer Strickland 16 Feb '24

16 Feb '24

Hi all - I’ve submitted a pull request to add the Official C++ Language Slack Workspace link to the website, can someone please merge this? https://github.com/boostorg/website/pull/815 Adding Slack link by 4down · Pull Request #815 · boostorg/website github.com Thanks, Spencer

2 1

Proposal to make Boost easily citable in academic works with Zenodo
by Hans Dembinski 15 Feb '24

15 Feb '24

Dear all, Nick Smith, an academic colleague, approached me with the question of how to cite Boost in academic works. As far as I am aware, we don't have a policy on that. Here is a proposal, mainly directed towards the admins of the Boost super-project on Github. Since a few years now zenodo.org <http://zenodo.org/> provides an easy to make software citable without requiring us to publish a paper in some journal. You can just sign in to Zenodo with your Github account and enable your repositories. On the next release, a Zenodo entry will be automatically generated, that academics can then cite easily. The procedure (with pictures) is explained here: https://inbo.github.io/tutorials/tutorials/git_zenodo I use Zenodo since a while for my scientific Python libraries and it works well. Once you set it up, it is a maintenance-free solution. It would be great if the admins of https://github.com/boostorg/boost would set this up for the Boost super-project, so that all of Boost becomes citable on the next release. Best regards, Hans

2 2

Preview Site Link for Boost Website Feedback
by Louis Tatta 13 Feb '24

13 Feb '24

In my last email, I forgot to include the preview link for the new Boost website. Here it is: https://www.preview.boost.org/ <http://preview.boost.org>. Please take a look and report any feedback or issues on our GitHub page: https://github.com/cppalliance/temp-site/issues. Thanks for your help. Louis C++ Alliance

3 3

Should boost::core::string_view be made public?
by Дмитрий Архипов 08 Feb '24

08 Feb '24

boost::core::string_view is a string_view implementation that (unlike boost::string_view from Utility) can interconvert with std::string_view. This functionality was necessary for Boost.JSON to drop the standalone mode, because people who have access to C++17 prefer to use std::string_view wherever they can. At the time there was no consensus on whether the type should be made public. Now in addition to Boost.JSON the type is also used at least by Boost.URL. And recently added Charconv is also using it. So, I want to raise the question again: should we make the type public and refer to it directly in our libraries' docs, rather than considering it an implementation detail?

5 21

Re: [boost] [Scope] Peer review conclusion
by Andrey Semashev 06 Feb '24

06 Feb '24

On 2/6/24 22:29, Дмитрий Архипов wrote: > Looks good to me. I consider the review conditions satisfied. Thank you Dmitry. And especially for taking the time to review the documentation and point out errors. > пн, 5 февр. 2024 г. в 03:47, Andrey Semashev <andrey.semashev(a)gmail.com>: > >> >> On 1/15/24 22:50, Дмитрий Архипов via Boost wrote: >>> Dear Boost community, the formal review of Boost.Scope has taken place >>> between 26th of November and 5th of December of the previous year. I >>> have received 5 reviews in total, including 4 here on the mailing list >>> and 1 on Reddit. Two of the reviews recommended unconditional, and 3 >>> conditional acceptance. The >>> reviews came from: >>> - Klemens Morgenstern, >>> - Janko Dedic, >>> - Julien Blanc, >>> - David Sankel, >>> - /u/jonesmz on Reddit. >>> >>> Also, several people have given insightful comments but did not provide a >>> review. I would like to thank all of the people who took their time to write >>> reviews or participate in the discussions. Your effort was very important and >>> valuable. >>> >>> The outcome of the review is that Boost.Scope is ACCEPTED with several minor >>> CONDITIONS. >>> >>> 1. noexcept specification on destructors of scope guards should be properly >>> documented. Andrey has already commented that the technical hurdle that >>> prevented it was eliminated. >>> >>> 2. There should be a good motivating example for scope_success. There was a lot >>> of comments regarding scope_success and its seeming uselessness. Without a >>> good example I see the same pattern occurring with future users. >>> >>> 3. The examples should better describe what they are trying to achieve. Several >>> comments about examples suggested incorrect changes, which signals that readers >>> failed to understand them. >>> >>> After a lot of consideration I decided against requesting the author to remove >>> unique_resource and related functionality from the library. While several >>> reviewers wanted a more "concise" library, all noted that the component is >>> useful. >>> >>> One last thing I wanted to point out is that all reviewers and most commenters >>> were adamant that compatibility with the Technical Specification on which this >>> library was initially based should not be a goal. In fact, Andrzej Krzemienski >>> even noted that such compatibility has prevented him from adequately evaluating >>> the library on its own merit. In my opinion this should be a sign to all of us >>> that people prefer better APIs over standard APIs. I recommend Andrey to >>> re-evaluate those parts of the library's APIs that he copied from the TS and >>> potentially pick better names for member functions. >>> >>> Thanks to Andrey for submitting this library to Boost. And thanks again to the >>> reviewers and everyone who provided feedback, who ultimately made this review >>> possible. >> >> I have updated the library according to review comments and conditions. >> To specifically address the acceptance conditions: >> >> 1. Noexcept specifications for destructors are now present in the docs. >> For example: >> >> https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/defer_guar… >> https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_exit… >> https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/unique_res… >> >> The fix for the BoostBook stylesheets is currently in develop. >> Hopefully, it will get merged to master soon. >> >> 2. I have added an example showing usage of all three conditional scope >> guards, including scope_success, here: >> >> https://lastique.github.io/scope/libs/scope/doc/html/scope/scope_guards.htm… >> >> The example is based on the one I posted during the review. >> >> 3. I have added more comments to some examples, as well as the >> discussion around them. For example, the examples on the front page are >> better commented now: >> >> https://lastique.github.io/scope/libs/scope/doc/html/index.html >> >> Some examples were modified or completely rewritten. For example, the >> locked_write_string was modified to reduce code duplication: >> >> https://lastique.github.io/scope/libs/scope/doc/html/index.html >> >> The leading example for unique_resource was rewritten: >> >> https://lastique.github.io/scope/libs/scope/doc/html/scope/unique_resource.… >> >> And a new example for unique_resource was added on the front page: >> >> https://lastique.github.io/scope/libs/scope/doc/html/index.html >> >> There are many more additions and modifications than I can mention here. >> >> >> There were also changes that were requested by reviewers or were the >> result of the discussion. The changelog here lists most of the changes: >> >> https://lastique.github.io/scope/libs/scope/doc/html/scope/changelog.html >> >> To mention the most prominent changes: >> >> * BOOST_SCOPE_FINAL was renamed to BOOST_SCOPE_DEFER and scope_final to >> defer_guard. >> * The `release()` member of scope guards was removed. `set_active()` is >> still present and is the way to activate and deactivate scope guards. >> * Added `operator bool()` to `unique_resource`. >> * Added a C++17 `unallocated_resource` class template that simplifies >> declaration of resource traits when all unallocated resource values can >> be listed. Along with the recently added to Boost.Core `functor` >> template, this can significantly reduce the amount of code one needs to >> write to declare a `unique_resource`. For example, a `unique_resource` >> for Windows handles could be declared like this: >> >> unique_resource< >> HANDLE, >> functor< CloseHandle >, >> unallocated_resource< INVALID_HANDLE_VALUE, (HANDLE)NULL > >> > handle; >> >> https://lastique.github.io/scope/libs/scope/doc/html/scope/unique_resource.… >> https://www.boost.org/doc/libs/develop/libs/core/doc/html/core/functor.html >> >> * `unique_resource` now enforces requirements on the resource traits >> with static asserts rather than falling back to the "no resource traits" >> mode of operation. >> * `unique_resource` no longer supports the "reduced" resource traits, >> where the traits were only used to customize the default resource value >> but not to distinguish allocated and unallocated resource values. >> * Added documentation sections discussing differences with the Library >> Fundamentals TS: >> >> https://lastique.github.io/scope/libs/scope/doc/html/scope/scope_guards.htm… >> https://lastique.github.io/scope/libs/scope/doc/html/scope/unique_resource.… >> >> * On the front page, removed comparison with Boost.ScopeExit from the >> table. There is a separate section for it: >> >> https://lastique.github.io/scope/libs/scope/doc/html/scope/scope_guards.htm… >> >> Also added another row to the table that shows explicit deactivation of >> the scope guards by calling `set_active(false)`. >> >> * There is now a section discussing caveats of capturing variables by >> reference in scope guards: >> >> https://lastique.github.io/scope/libs/scope/doc/html/scope/scope_guards.htm… >> >> There are probably other changes that I forgot to mention. >> >> >> Dmitry, please let me know if you consider the review conditions >> satisfied or if there needs to be done something more. >> >> If everything's fine, what needs to be done to move the library into >> boostorg? >>

1 0

Re: [boost] critical bugs in charconv
by g.peterhoff＠t-online.de 05 Feb '24

05 Feb '24

> So what's your point? Another example. I had asked for a TypeTrait is_integer and also supplied code for it (https://github.com/boostorg/type_traits/issues/186) The point is that is_integer only returns integer (no character, no bool). John immediately closed my request "We are not responsible for that". Instead of admitting a mistake (of course I make some myself) and saying "we forgot/didn't think of it, we'll do it", the only answer is "we don't care". That's thinking from the wallpaper to the wall. As I said, boost used to be progressive, but now when you make a suggestion, all you get is "We're not responsible for that/we're not interested in that/we might have to change something that's not possible" And this even with such a simple TypeTrait. Single file. No dependencies. And on the other hand, libraries with the most severe buffer overflows (charchonv) are included, where obviously no tests are carried out at all.

5 5

Re: [boost] critical bugs in charconv
by g.peterhoff＠t-online.de 05 Feb '24

05 Feb '24

> So what's your point? a) boost/math/policies/error_handling.hpp manual name_of, although it would be no problem to add a simple nameof in boost/core/demagle.hpp: template <typename Type> inline std::string nameof() { return demangle(typeid(Type).name()); } b) boost/math/policies/policity.hpp manual "variadic templates" c) boost.convert (apart from the fact that this library is unusable due to its design) - no C++23 FP types - no (unsigned)__int128 - no __float128 These are just the things that came to my mind. The whole design and supported types of boost is stuck 25 years ago. As I said, I'm grateful that boost made C++11 possible. But since then you are stuck at this level and changes are *not* welcome.

2 1

critical bugs in charconv
by g.peterhoff＠t-online.de 05 Feb '24

05 Feb '24

Hello Matt, Sorry for submitting a bug report this way. (Having problems with my GitHub account at the moment). Code: Attachment (gcc 13.2 -std=gnu++23 -O3 -Wall -fanalyzer) Errors (normal) - Missing sign - Hex exponent is wrong - Hex is completely wrong - Accuracy is not correct - Error code deviates from the standard ... The backup functions via (quadmath)snprintf do not work. Errors (critical) - If the buffer is too small (e.g. set the array size to 3) there are a lot of buffer overflows. Especially with value ±nan/±inf. The functions should therefore always be structured in the same way: Auxiliary function inline constexpr bool is_valid_range(const char*const first, const char*const last) noexcept { return (first!=nullptr && last!=nullptr) ? first < last : false; } Pseudocode to_chars(...) // FP { to_chars_result result{last, std::errc::value_too_large}; if (is_valid_range(first, last)) [[likely]] { const size_t size = size_t(last - first); if (inf or nan) [[unlikely]] { if (size is large enough) { copy the string values into the range result = ...; Here you could also use #define to specify whether the string values are compatible with the standard or not. "±inf", "±nan" or https://develop.charconv.cpp.al/#to_chars_usage_notes_for_to_chars_for_floa… } } else { convert, detail::implemantation(first, size, ...) result = ...; } } return result; } to_chars(...) // INT { to_chars_result result{last, std::errc::value_too_large}; if (is_valid_range(first, last)) [[likely]] { const size_t size = size_t(last - first); convert, detail::implemantation(first, size, ...) result = ...; } return result; } This can be achieved with templates and typetraits: FP boost::is_floating_point still does not contain any C++23 types. template <typename Type> BOOST_NOINLINE typename std::enable_if<std::is_floating_point<Type>::value, to_chars_result>::type to_chars(char*const first, char*const last, const Type value, const chars_format format, const int precision) noexcept; template <type name Type> BOOST_NOINLINE typename std::enable_if<std::is_floating_point<Type>::value, to_chars_result>::type to_chars(char*const first, char*const last, const Type value, const chars_format format) noexcept; INT (boost)is_integer is unfortunately still missing. template <type name Type> BOOST_NOINLINE typename std::enable_if<boost::is_integer<Type>::value, to_chars_result>::type to_chars(char*const first, char*const last, const Type value, const int base = 10) noexcept; regards Gero

4 5

[Scope] Peer review conclusion
by Дмитрий Архипов 05 Feb '24

05 Feb '24

Dear Boost community, the formal review of Boost.Scope has taken place between 26th of November and 5th of December of the previous year. I have received 5 reviews in total, including 4 here on the mailing list and 1 on Reddit. Two of the reviews recommended unconditional, and 3 conditional acceptance. The reviews came from: - Klemens Morgenstern, - Janko Dedic, - Julien Blanc, - David Sankel, - /u/jonesmz on Reddit. Also, several people have given insightful comments but did not provide a review. I would like to thank all of the people who took their time to write reviews or participate in the discussions. Your effort was very important and valuable. The outcome of the review is that Boost.Scope is ACCEPTED with several minor CONDITIONS. 1. noexcept specification on destructors of scope guards should be properly documented. Andrey has already commented that the technical hurdle that prevented it was eliminated. 2. There should be a good motivating example for scope_success. There was a lot of comments regarding scope_success and its seeming uselessness. Without a good example I see the same pattern occurring with future users. 3. The examples should better describe what they are trying to achieve. Several comments about examples suggested incorrect changes, which signals that readers failed to understand them. After a lot of consideration I decided against requesting the author to remove unique_resource and related functionality from the library. While several reviewers wanted a more "concise" library, all noted that the component is useful. One last thing I wanted to point out is that all reviewers and most commenters were adamant that compatibility with the Technical Specification on which this library was initially based should not be a goal. In fact, Andrzej Krzemienski even noted that such compatibility has prevented him from adequately evaluating the library on its own merit. In my opinion this should be a sign to all of us that people prefer better APIs over standard APIs. I recommend Andrey to re-evaluate those parts of the library's APIs that he copied from the TS and potentially pick better names for member functions. Thanks to Andrey for submitting this library to Boost. And thanks again to the reviewers and everyone who provided feedback, who ultimately made this review possible.

3 5

[charconv] Review Results and Report
by Christopher Kormanyos 02 Feb '24

02 Feb '24

Dear Boost Community, The review of the proposed Boost.Charconv is finished It took place 15-25 January 2024. REVIEW RESULT ----------------------------- The result is Boost.Charconv is unconditionally * ACCEPTED * into Boost. Thank you Matt. Boost.Charconv will enrich Boost and surely be used vigorously. REVIEW REPORT ----------------------------- The review tally is: * 1 Conditional ACCEPT * 4 ACCEPT * 1 Positive Document Review ---------------------------- = 5 ACCEPT, since the single condition has already been satisfied in develop branch. My Comments and Descriptions below are based on limited knowledge and my subjective interpretations. Please correct, add, modify these (and to these) as needed. * Comments: The review atmosphere was highly productive and excellent. Reviews and contributions featured deep technical content and detail. Fact-based statements combined with experienced-based opinions were provided. There was great strength of expression and clarity. Yet there was mutual respect and fairness, even in the course of lively debate. * Descriptions: Ultimately there were three areas receiving the most debate. For background, see references below. 1) The library needs to allocate. Among other conversions, Boost.Charconv handles conversion of floating-point values to chars. Edge-cases may require hundreds or even thousands of bits. * Consensus: Handle the required memory needed, as done, with low-level C-LIB malloc. But do describe this decision with greater depth of clarity in the docs. 2) The project makes use of a variety of methods, including some table-driven methods. One example is RYU (see [1]). A quick glance at Fig. 4 in [1], for instance, reveals the need for relatively large, constant-valued tables. Largescale tables, combined with the C++11 design goal formed a clear indication to produce a compiled library (as opposed to a header-only one). * Consensus: Compiled-library is sound and viable. Tables (especially in constexpr-context) might bloat or not even work in some language-standards environments. Some commenters, however, seemed subjectively to disapprove of this consensus, feeling that header-only offers the best chances at friction-free setup and convenient portability. Other commenters revealed a sense that compiled libraries are gaining traction in the industry. They feel that this is because the community, their available tools, language-skills, specifications, compilers, CI, VMs, etc. have matured significantly and continue to mature. Thereby they embrace a perceived future-oriented trend that views client-builds to be uncomplicated. There were no blockers on the consensus. 3) The top-level interface differs from that of std-<charconv> in points such as overloads and error-handling. Whereas some details are not even fully hashed-out in the Standard. * Consensus: Weigh known opinions and decide interface details based on unbiased majority. My current understanding is: Offer two drop-ins for from_chars, with the caveat that one should provide better error-handling. REVIEW ACKNOWLEDGMENTS ----------------------------- Thanks again, Matt for Boost.Charconv. Many thanks to our expert reviewers, commenters and watchers. Your contributions keep Boost excellent! Kindest regards, Christopher Kormanyos Boost.Charconv Review Manager * References: [1] Ulf Adams, "RYU: fast float-to-string conversion", ACM SIGPLAN Notices, Volume 53, Issue 4, pp 270–282 (ACM 2018) [2] "Number Parsing at a Gigabyte per Second", Daniel Lemire's Blog, https://lemire.me/blog/2021/01/29/number-parsing-at-a-gigabyte-per-second/ [3] https://github.com/lemire/fast_double_parser

1 0

[charconv] Review Results and Report
by Christopher Kormanyos 02 Feb '24

02 Feb '24

Dear Boost Community, The review of the proposed Boost.Charconv is finished It took place 15-25 January 2024. REVIEW RESULT ----------------------------- The result is Boost.Charconv is unconditionally * ACCEPTED * into Boost. Thank you Matt. Boost.Charconv will enrich Boost and surely be used vigorously. REVIEW REPORT ----------------------------- The review tally is: * 1 Conditional ACCEPT * 4 ACCEPT * 1 Positive Document Review ---------------------------- = 5 ACCEPT, since the single condition has already been satisfied in develop branch. My Comments and Descriptions below are based on limited knowledge and my subjective interpretations. Please correct, add, modify these (and to these) as needed. * Comments: The review atmosphere was highly productive and excellent. Reviews and contributions featured deep technical content and detail. Fact-based statements combined with experienced-based opinions were provided. There was great strength of expression and clarity. Yet there was mutual respect and fairness, even in the course of lively debate. * Descriptions: Ultimately there were three areas receiving the most debate. For background, see references below. 1) The library needs to allocate. Among other conversions, Boost.Charconv handles conversion of floating-point values to chars. Edge-cases may require hundreds or even thousands of bits. * Consensus: Handle the required memory needed, as done, with low-level C-LIB malloc. But do describe this decision with greater depth of clarity in the docs. 2) The project makes use of a variety of methods, including some table-driven methods. One example is RYU (see [1]). A quick glance at Fig. 4 in [1], for instance, reveals the need for relatively large, constant-valued tables. Largescale tables, combined with the C++11 design goal formed a clear indication to produce a compiled library (as opposed to a header-only one). * Consensus: Compiled-library is sound and viable. Tables (especially in constexpr-context) might bloat or not even work in some language-standards environments. Some commenters, however, seemed subjectively to disapprove of this consensus, feeling that header-only offers the best chances at friction-free setup and convenient portability. Other commenters revealed a sense that compiled libraries are gaining traction in the industry. They feel that this is because the community, their available tools, language-skills, specifications, compilers, CI, VMs, etc. have matured significantly and continue to mature. Thereby they embrace a perceived future-oriented trend that views client-builds to be uncomplicated. There were no blockers on the consensus. 3) The top-level interface differs from that of std-<charconv> in points such as overloads and error-handling. Whereas some details are not even fully hashed-out in the Standard. * Consensus: Weigh known opinions and decide interface details based on unbiased majority. My current understanding is: Offer two drop-ins for from_chars, with the caveat that one should provide better error-handling. REVIEW ACKNOWLEDGMENTS ----------------------------- Thanks again, Matt for Boost.Charconv. Many thanks to our expert reviewers, commenters and watchers. Your contributions keep Boost excellent! Kindest regards, Christopher Kormanyos Boost.Charconv Review Manager * References: [1] Ulf Adams, "RYU: fast float-to-string conversion", ACM SIGPLAN Notices, Volume 53, Issue 4, pp 270–282 (ACM 2018) [2] "Number Parsing at a Gigabyte per Second", Daniel Lemire's Blog, https://lemire.me/blog/2021/01/29/number-parsing-at-a-gigabyte-per-second/ [3] https://github.com/lemire/fast_double_parser

1 0

Using ASIO to wait on a foreign socket being readable, with a timeout
by Dominique Devienne 31 Jan '24

31 Jan '24

Hi, I'm trying to use ASIO to wait until a socket is ready to read, or timeout. This is a blocking wait. But the socket is not "owned" by ASIO, but is from the libpq PostgreSQL connection. So ASIO should NOT consume any of the input on the socket, just notify me when that socket is "read-ready". I've cobbled together the following test code: ``` const int socket2 = PQsocket(conn2.handle()); BOOST_CHECK(socket2 > 0); int timr_err_code = 0; int sock_err_code = 0; bool timr_aborted = false; bool sock_aborted = false; std::string timr_err_msg; std::string sock_err_msg; bool timed_out = true; auto c1 = "C# 1"sv; conn2.listen(c1); conn1->notify(c1, "wake up!"sv); { boost::asio::io_context io_ctx; boost::asio::ip::tcp::socket io_sock(io_ctx); io_sock.assign(boost::asio::ip::tcp::v4(), socket2); boost::asio::steady_timer io_timer(io_ctx); io_timer.expires_from_now(std::chrono::milliseconds(100)); io_sock.async_wait( io_sock.wait_read, [&](const boost::system::error_code& errc) { if (errc) { sock_err_code = errc.value(); sock_err_msg = errc.message(); sock_aborted = (errc == boost::asio::error::operation_aborted); } timed_out = false; //io_timer.cancel(); io_ctx.stop(); } ); io_timer.async_wait( [&](const boost::system::error_code& errc) { if (errc) { timr_err_code = errc.value(); timr_err_msg = errc.message(); timr_aborted = (errc == boost::asio::error::operation_aborted); } io_sock.cancel(); io_ctx.stop(); } ); io_ctx.run(); // blocks until either async op above runs } // there's a notif to read, so io_sock.async_wait should have completed BOOST_CHECK_EQUAL(timr_err_code, 0); BOOST_CHECK_EQUAL(sock_err_code, 0); BOOST_CHECK_EQUAL(timr_err_msg, ""); BOOST_CHECK_EQUAL(sock_err_msg, ""); BOOST_CHECK_EQUAL(timr_aborted, false); BOOST_CHECK_EQUAL(sock_aborted, false); BOOST_CHECK_EQUAL(timed_out, false); auto notif = conn2.notification(); BOOST_REQUIRE(notif); BOOST_CHECK_EQUAL(notif.backend_pid(), pid1); BOOST_CHECK_EQUAL(notif.channel(), c1); BOOST_CHECK_EQUAL(notif.payload(), "wake up!"sv); ``` The io_sock.async_wait(io_sock.wait_read, ...) succeeds, the IO loop stops as expected, but when I try to PQconsumeInput() from the LIBPQ connection next (as shown in the code below) ``` Notification Connection::notification() { auto [lock, hndl] = ensure_handle(); if (1 != PQconsumeInput(hndl)) { throw std::runtime_error(error_msg()); // <<<<<< THROWS } PGnotify_uptr notif{ PQnotifies(hndl) }; return Notification(std::move(notif)); // may be null } ``` that calls fail with this error message: fatal error: in "NotificationTests/test_across_backends": class std::runtime_error: could not receive data from server: Socket operation on non-socket (0x00002736/10038) LIBPQ didn't like what ASIO somehow did on the socket descriptor. The LIBPQ doc says to select() the descriptor, but I thought ASIO would be cleaner, more C++, and perhaps more cross-platform. Can somehow help, telling me if I'm using ASIO incorrectly here? Thanks, --DD

3 2

Boost.Charconv review runs January 15th - 25th, 2024
by Christopher Kormanyos 31 Jan '24

31 Jan '24

Dear all, The review of Boost.Charconv by Matt Borland runs Monday, January 15th through January 25th, 2024. Code: https://github.com/cppalliance/charconvDocs: https://master.charconv.cpp.al/Review Schedule: https://www.boost.org/community/review_schedule.html Thank you for considering this review. Please optionally provide feedback on the followinggeneral topics: - 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? Christopher KormanyosBoost.Charconv Review Manager

15 76

[charconv] is std::from_chars practical?
by Andrzej Krzemienski 26 Jan '24

26 Jan '24

Hi Everyone, This is about https://github.com/cppalliance/charconv/issues/110, again. Now I understand Peter's point better. std::from_chars is impractical, or one would say "broken", at least for the case of ERANGE. Actually applying a patch in https://cplusplus.github.io/LWG/lwg-active.html#3081 will not make the tool good, it will just make it broken in another way. In that case, maybe the goal of providing literally a *drop-in replacement* for std::from_chars is not a good one? Maybe this is the case similar to variant2, where the community would benefit more from the library motivated by "how would from_chars look like if we designed it instead of WG21". That is, an *alternative to* std::from_chars, rather than a *drop-in-replacement for* std::from_chars. Regards, &rzej;

6 6

Review of proposed CharConv
by Antony Polukhin 25 Jan '24

25 Jan '24

## What is your evaluation of the design? Design follows the C++ Standard library design with all the latest additions. Everything is fine. ## What is your evaluation of the implementation? Fine in general. A few nitpicks/concerns follow. ### Arrays of constants RYU/fast_float/... are used for some of the conversions and most of those algorithms have huge tables full of constants. For example https://github.com/cppalliance/charconv/blob/41a83261c0f65aee575e89ccb71d94… and https://github.com/cppalliance/charconv/blob/41a83261c0f65aee575e89ccb71d94… and https://github.com/cppalliance/charconv/blob/41a83261c0f65aee575e89ccb71d94… Those constants have internal linkage. They are put in every translation unit that includes and uses them. Those constants would not be merged by linker. Moreover, the same constants with different names now exist in Standard Library implementations and are not merged with Boost.Charconv. To reduce the binary size and improve data locality I'd recommend switching to std implementation in sources if the feature test macro tells that std::to_chars/std::from_chars are fine. ### Internal headers in include/ Some of the headers are used only internally during build. It seems reasonable to move them to the src/ directory to make sure that no one uses them and that the library itself does not include them by accident. ### Header only support There is a PR to make the library header only https://github.com/cppalliance/charconv/pull/138 This feature is demanded by users however it raises the constants question again. Marking arrays of constants with `inline` should be done to make the constants externally visible, so that the linker could merge them. ### Constexpr for floats Just a feature request - it would be nice to have constexpr from_chars and constexpr to_chars for floating point types. If is_constant_evaluated() - do slow but constexpr conversion. Otherwise - fallback to std:: version or to the implementation in src/ ### Locales Locales are used in some corner cases along with switching them back and forth https://github.com/cppalliance/charconv/blob/41a83261c0f65aee575e89ccb71d94… Looks like there's no need in that line for locales switching. Just get the decimal point separator from the current locale and if it is not '.' then do the replacement of the first '.' to the locale's separator. ### Nitpicks Looks like zero initialization of the buffers could be skipped in following places: * https://github.com/cppalliance/charconv/blob/41a83261c0f65aee575e89ccb71d94… * https://github.com/cppalliance/charconv/blob/41a83261c0f65aee575e89ccb71d94… * https://github.com/cppalliance/charconv/blob/41a83261c0f65aee575e89ccb71d94… ## What is your evaluation of the documentation? Looks like parts of the docs repeat themself. For example, the reference section duplicates some of the previous descriptions. The latter could be just removed. Another thing that catches an eye are the benchmarks. Please also provide some absolute numbers because "X is five times faster than Y" could easily be that X and Y execute for ~1ns each. Those numbers are profitable for users. Side Note for myself: Seems that LexicalCast shows poor performance in some cases where it should not. Will investigate. ## What is your evaluation of the potential usefulness of the library? Very useful for libraries that wish to support pre-C++17 standards or a wide range of compilers. Useful for experimenting and prototyping new C++ Standard Library proposals ## 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? Just looked through the code and the docs. ## Are you knowledgeable about the problem domain? I'm maintaining the Boost.LexicalCast and implemented a bunch of optimizations for std::to_chars/std::from_chars for the libstdc++. I'm not knowledgeable of RUY internals, but have the general understanding of the <charconv>. ## Do you think the library should be accepted as a Boost library? Yes

3 2

Zach Laine CharConv review
by Zach Laine 25 Jan '24

25 Jan '24

- What is your evaluation of the design? It follows the design of the equivalent facility in std::, so this feels moot. No complaints with that part. My only complaint is that the semantics of boost::charconv::from_chars and boost::charconv::from_chars_strict seem backward to me. I know this was mentioned by other reviewers. I think that with near-identity to the standard version, having the same (or corresponding name within boost::) should imply the same semantics. This is classic adherence to The Principle of Least Surprise. I would much prefer that the varying version have the different name, and that the one with the standard's semantics should be from_chars. I also encourage the authors to track any changes to std::from_chars with boost::charconv::from_chars. - What is your evaluation of the implementation? I mean, there's a lot of it. I'm sure it's all necessary, but I only looked at about 10% of it. What I saw seemed reasonable and well organized. - What is your evaluation of the documentation? It's great. The library is smallish, and the docs are correspondingly bite-sized, with plenty of examples. I might add a little more front matter that explains why someone should use this library. The docs get there, but putting it in the first paragraph is better. Busy people will blow right past everything that isn't in the first paragraph or two. - What is your evaluation of the potential usefulness of the library? High. I think the fact that this is a C++17 feature that we still can't reliably use says it all. The fact that it's about the same as the std:: implementation, or sometimes a little faster, is even better. - Did you try to use the library? With what compiler? Did you have any problems? Yes. I tried it with GCC 12, in a small test program just to see it go. No issues. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent about 3 hours, mostly looking at code. I also read all the docs and gave it a quick try. - Are you knowledgeable about the problem domain? Not particularly. I have written lots and lots of parsers, but never a simple low-level one like those in charconv. Zach

3 3

test message 19
by Sam Darwin 24 Jan '24

24 Jan '24

content test message 19

1 0

test message 7
by Sam Darwin 18 Jan '24

18 Jan '24

contents of test message 7 ___

1 0

Review of Parser library scheduled
by Mateusz Loskot 17 Jan '24

17 Jan '24

Folk, Review of Zach Laine's Praser library has been scheduled [1] for February 19, 2024 - February 28, 2024 Big thanks to Marshall Clow for volunteering to be the review manager. [1] https://www.boost.org/community/review_schedule.html Best regards, -- Mateusz Loskot on behalf of Boost Review Wizards

1 0

Making Boost modular. IMPORTANT! URGENT! <insert-superlative-here>!
by René Ferdinand Rivera Morell 17 Jan '24

17 Jan '24

Dear fellow Boost authors, As some of you may have heard.. Some of us have been working on making it possible to fully consume Boost in a modular arrangement. First some FAQs about this: Q: What is a "modular arrangement"? A: It's when the libraries can be used, and hence built, without creating the monolithic headers, without needing the root build files, and without needing the libraries to be arranged in the usual root/libs/<name>. Q: Will a modular Boost remove the Boost release? A: No. The collection of libraries is still a single release. See recent discussions about this. Q: Will this change the testing? A: No, unless you want to. You will still be able to test the same non-modular way. But you could also test the modular way. Q: Will this require that we change the current Boost source structure? A: Yes. Unfortunately there is one restriction that adhering to a modular Boost requires. We would not allow sublibs. That is, that we can't support having libraries in root/libs/thing/<library> style locations. All libraries must be single libraries under the root/libs directory. Thankfully there's only a handful of such libraries. The root/libs/numeric/* group of libraries. Q: Why do we want a modular Boost? A: I'm not going to enumerate the reasons here. But let me just say.. That we've wanted a way to reduce, i.e. modularize, Boost since at least 19 years ago. When we added the "--without-<library>" build option to the root build file <https://github.com/boostorg/boost/blame/master/Jamroot#L107>. Now the work part.. Over the past year or so I've been making patches to the Boost build files, in my own repo, that cleans up the many, many, problems that make libraries depend on the current source structure. I've also made changes to B2 to make it easier/possible/automatic to deal with the new modular freedom. The B2 changes were naturally easy to put in since I control the repo and distribution. And the last bit of them shipped with the 1.83 release last Summer. But now I need to start pushing the changes to the many Boost repos to get this finished. A couple of weeks ago I started posting PRs to incrementally, and unobtrusively, make the changes to the Jamfiles. So far I have these: <https://github.com/boostorg/ublas/pull/189> <https://github.com/boostorg/interval/pull/38> I'm not sure how else to say this so.. PLEASE, PLEASE, merge those and future PRs ASAP. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

7 12

Boost downloads and JFrog
by Glen Fernandes 13 Jan '24

13 Jan '24

Rather than emails and Slack DMs, I would prefer we have this discussion on the mailing list. To summarize what I have repeated in the aforementioned channels: - Yes, our downloads are not working again because the JFrog account is again not active. - No, I cannot do anything about the JFrog account. - Yes, we can update the website to point to downloads hosted elsewhere. It is correct that JFrog does not charge us yet but our traffic has increased from 60TB/month to almost 200TB/month which is no longer supportable for free. We have limited time to find a solution. We are on borrowed time but as far as I know we still have time. the deactivation of the JFrog account in December 31 was not expected, and it was reinstated. Glen

12 39

Request for comments: to_static_string
by Ruben Perez 13 Jan '24

13 Jan '24

Hi all, Since we will be reviewing Boost.CharConv shortly, and my development efforts in Boost.MySQL are currently requiring converting numbers to strings, I've been playing with the utilities we currently have to do so. I've found cases where I just needed to convert something to string, then pass the result to another function taking a string_view as parameter. The most efficient and correct way to do so is using to_chars (stack based, non-throwing, C++23 constexpr and locale-independent). But I still like the simplicity of std::to_string. Since I had some free time this weekend, I took a step forward and implemented a (deadly simple) wrapper around to_chars that looks like std::to_string, but has all the benefits of to_chars. I called this to_static_string. Repo is here: https://github.com/anarthal/to-static-string This is currently a prototype. I want to hear everyone's opinion on this - do you think this may be useful to any of you? I don't think it's big enough to even consider putting it into Boost (my idea is having it as a standalone lib). Any comments are welcome. Thanks, Ruben.

2 3

[scope] Some random thoughts
by Andrzej Krzemienski 10 Jan '24

10 Jan '24

Hi All, Two observations from reading the docs. Why do I need a condition in scope_exit when I have a scope_fail? I recommend putting warning somewhere in the docs that while using scope guards you may inadvertently read an object after move: std::string checked(std::string name) { scope::scope_exit g{[&]{ std::clog << "checked " << name <<std::endl; }}; validate(name); return name; // name becomes moved-from } Regards, &rzej;

3 5

Forthcoming Boost.Charconv review January 15th - 25th, 2024
by Christopher Kormanyos 09 Jan '24

09 Jan '24

Dear all, The review of Boost.Charconv by Matt Borland is scheduledfrom Monday, January 15th to January 25th, 2024. ----------------------------------------------------- About the library: Boost.Charconv provides a highly portable and efficient, C++11 implementation of <charconv>. The API containsfunctions compatible with <charconv>. Boost.Charconv can be highly useful for portability and efficiency. The standard library's <charconv> requires C++17 or higher. Currently only quite modern compilers such as GCC 11+ and MSVC 19.24+ support both integer and floating-point conversions in their implementation of <charconv>. If you are using either of those compilers, Boost.Charconv is at least as performant as <charconv>, and can be up to several times faster. If you are using an older compiler or a language standard lower than C++17, then there is no <charconv> available. In such cases, Boost.Charconv provides a highly-viable, portable and efficient header-only implementation. Boost.Charconv is a compiled library and does require a few other Boost libraries to run. The docs providedirections for how to consume with b2, vcpkg and Conanto facilitate this. Boost.Charconv fits into Boost stylistically and through itshigh quality, its Boost-like testing and its documentation. Boost.Charconv has been well-received and endorsed on the Boost-lists and is already being used for prototyping in several existing Boost libraries. Tool vendors have expressed interest in Boost.Charconv particularly due to its high performance and clarity of implementation details. docs: https://develop.charconv.cpp.al git: https://github.com/cppalliance/charconv --------------------------------------------------- Naturally, you need not wait until the review formally opens to start reviewing the Charconv library. Please always state in your review whether you think the library should be accepted as a Boost library! Please consider giving feedback on the following general topics: - 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? Christopher Kormanyos Boost.Charconv Review Manager ------------------------------

2 2

boost.sqlite
by Klemens Morgenstern 06 Jan '24

06 Jan '24

I've written a boost.sqlite library last year mainly to experiment, but it has been a feature-complete C++ wrapper for a while. Hence I'd like to gauge interest to see if it's worth proposing for boost. It has more features than most C++ sqlite wrappers and uses boost-isms such as system.result, tag_invoke and boost.json. Code: https://github.com/klemens-morgenstern/sqlite Docs: https://klemens.dev/sqlite/

5 9

Re: [boost] Interest in new parsing library?
by tobi＠die-loews.de 06 Jan '24

06 Jan '24

Zach Laine wrote: > - use approximately the same set of directives to influence the parse > (e.g. lexeme[]); It seems there is no directive like Spirit's no_case. Is there a way to match case-insensitivity?

2 2

Google Summar of Code 2024 - Collecting Projects & Mentors! 📢
by Inbal Levi 05 Jan '24

05 Jan '24

Hello all! We would like to collect projects & mentors for the GSOC 2024 :) If you would like to volunteer as a mentor and/or have a proposal for a Boost project which you like to collect volunteers for, please fill in the proper tab: https://docs.google.com/spreadsheets/d/1_eUWRsXnhi_JwKZbHZsGQf3WNUESsAPE4lV… Once we have a list of proposed projects, we will upload them to GitHub. Thanks! Best regards, Inbal Levi ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Lead Software Engineer @ Millenium* Isocpp, Boost &"Hamakor" Non-Profits Board Member ISO C++ LEWG Chair & Israeli NB Chair C++Now Program Chair & CoreC++ Conference Organizer ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

Recommendations for documentation authors
by Andrzej Krzemienski 04 Jan '24

04 Jan '24

Hi Boost Developers, And a happy New Year (at least for those who recognize the Gregorian calendar). While I consider improving the documentation quality of some Boost libraries, I wonder if there are any tool or workflow recommendations for the library authors regarding the documentation. I know we do not force any specific tool or format, so I am only asking about recommendations. I note that page https://www.preview.boost.org has at https://www.preview.boost.org/doc/contributor-guide/docs/documentation-guid… the following: > The format for documentation on the new website is AsciiDoc Syntax Quick Reference <https://docs.asciidoctor.org/asciidoc/latest/syntax-quick-reference/>. Should I treat it as a recommendation to use AsciiDoc? I note that quite a few new libraries choose it. I also see the advantage: you need no special tool for it: a simple web browser knows how to format it. But I found the documentation of libraries that use adoc to be uncomfortable to read. I do not know if this is the tool itself or maybe the correlation between the choice of the tool and the devotion to documentation quality, or maybe something else. It is quite subjective. The older libraries' documentation (using BoostDoc) seemed more friendly and easier to navigate. But to write and maintain such documentation is a challenge. Last year something broke in my pipeline (QuickDoc, xstlproc) and to this day I am not able to determine what it is. So, relying on too complex flows, which become obsolete over time, also doesn't seem like a good idea. I wonder if any of you have similar thoughts, and if you can recommend something for writing good quality and user friendly documentation. Regards, &rzej;

9 23

[website][string_ref] Broken link to the library docs
by Andrey Semashev 02 Jan '24

02 Jan '24

Hi, In the library list for Boost 1.84: https://www.boost.org/doc/libs/1_84_0/ there is an entry for Boost.StringRef. However, that library was removed from libs/utility/meta/libraries.json. Or, more precisely, it was renamed to Boost.StringView (key: utility/string_view). The problem is that the StringRef entry in the above list has a broken link to the library docs, and the rename was supposed to fix it (by having an entry for StringView instead, linking to its docs). I'm not sure where StringRef comes from, but can it be removed? This has been reported a few times already: https://github.com/boostorg/website/issues/763 https://github.com/boostorg/utility/issues/105

1 0

Interest in new parsing library?
by Zach Laine 30 Dec '23

30 Dec '23

I'm trying to gauge interest in a parsing library to replace Boost.Spirit 2/Spirit X3. I'm also looking for endorsements. The library is intended to remedy some shortcomings of Boost.Spirit*. I think these are great libraries, but Spirit 2 was written in pre-11 C++ (I think; certainly its dependencies were). Most-to-all of the downsides stem from that -- long compile times, inscrutable compilation failures, etc. (Boost.Parser compile times are quite low.) I'm calling my proposal Boost.Parser, and it follows many of the conventions of Boost.Spirit 2 and X3, such as the operators used for overloading, the names of many parsers and directives, etc. It requires C++17 or later. >From the introduction in the online docs: """ Boost.Parser is a parser combinator library. That is, it consists of a set of low-level primitive parsers, and operations that can be used to combine those parsers into more complicated parsers. There are primitive parsers that parse epsilon (the empty string), chars, ints, floats, etc. There are operations which combine parsers to create new parsers. For instance, the Kleene star operation takes an existing parser p and creates a new parser that matches zero or more occurrences of whatever p matches. Both callable objects and operator overloads are used for the combining operations. For instance, operator*() is used for Kleene star, and you can also write repeat(n)[p] to create a parser for exactly n repetitions of p. Boost.Parser also tries to accommodate the multiple ways that people often want to get a parse result out of their parsing code. Some parsing may best be done by returning an object that represents the result of the parse. Other parsing may best be done by filling in a preexisting data structure. Yet other parsing may best be done by parsing small sections of a large document, and reporting the results of subparsers as they are finished, via callbacks. Boost.Parser accommodates all these ways of working, and even makes it possible to do callback-based or non-callback-based parsing without rewriting any code (except by changing the top-level call from parse() to callback_parse()). All of Boost.Parser's public interfaces are sentinel- and range-friendly, just like the interfaces in std::ranges. Boost.Parser is Unicode-aware through and through. When you parse ranges of char, Boost.Parser does not assume any particular encoding — not Unicode or any other encoding. Parsing of inputs other than plain chars assumes that the input is Unicode. In the Unicode-aware code paths, all parsing is done by matching code points. This means that you can feed UTF-8 strings into Boost.Parser, both as input and within your parser, and the right sort of matching occurs. For instance, if your parser is trying to match repetitions of the char '\xcc' (which is a lead byte from a UTF-8 sequence, and so is malformed UTF-8 if not followed by an appropriate UTF-8 code unit), it will not match the start of "\xcc\x80" (UTF-8 for the code point U+0300). Boost.Parser knows that the matching must be whole-code-point, and so it interprets the char '\xcc' as the code point U+00CC. Error reporting is important to get right, and it is important to make errors easy to understand, especially for end-users. Boost.Parser produces runtime parse error messages that are very similar to the diagnostics that you get when compiling with GCC and Clang (it even supports warnings that don't fail the parse). The exact token associated with a diagnostic can be reported to the user, with the containing line quoted, and with a marker pointing right at the token. Boost.Parser takes care of this for you; your parser does not need to include any special code to make this happen. Of course, you can also replace the error handler entirely, if it doesn't fit your needs. Debugging complex parsers can be a real nightmare. Boost.Parser makes it trivial to get a trace of your entire parse, with easy-to-read (and very verbose) indications of where each part of the trace is within the parse, the state of values produced by the parse, etc. Again, you don't need to write any code to make this happen — you just pass a parameter to parse(). Dependencies are still a nightmare in C++, so Boost.Parser can be used as a purely standalone library, independent of Boost. """ Boost.Parser aims to be a superset of Boost.Spriit* in most ways. Major things missing from the set of features in Spirit 2 + Spirit X3 are: - A separate lexer. - Binary parsers (meaning for parsing bits, not binary numbers written as text; the latter is fully supported). I've been in touch with Joel de Guzman, Hartmut Kaiser, and Michael Caisse, to make sure I was not toe-stomping, for those who are concerned about that. They gave this new library their blessing. One feature comes entirely from them: Boost.Parser is usable in a Boost-free environment -- as a standalone library -- at the user's option. They said that was the #1 request from users, which surprised me a bit. The Github page is here: https://github.com/tzlaine/parser The online docs are here: https://tzlaine.github.io/parser To see an extended example, here's a JSON parser that passes all the published JSON tests, including most of the optional ones, in only about 300 lines of code, go here: https://tzlaine.github.io/parser/doc/html/boost_parser__proposed_/extended_… Finally, for those wanting to know how this lib differs from Boost.Spirit* without digging through the docs, here is the doc page that explains Boost.Parser's relationship to Boost.Spirit*: """ Boost.Spirit is a library that is already in Boost, and it has been around for a long time. However, it does not suit user needs in some ways. Spirit 2 suffers from very long compile times. Spirit 2 has error reporting that requires a lot of user intervention to work. Spirit 2 requires user intervention, including a (long) recompile, to enable parse tracing. Spirit X3 has rules that do not compose well — the attributes produced by a rule can change depending on the context in which you use the rule. Spirit X3 is missing many of the convenient interfaces to parsers that Spirit 2 had. For instance, you cannot add parameters to a parser. All versions of Spirit have Unicode support, but it is quite difficult to get working. I wanted a library that does not suffer from any of the above limitations. It should be noted that while Spirit X3 only has a couple of flaws in the list above, the one related to rules is a deal-breaker. The ability to write rules, test them in isolation, and then re-use them throughout a complex parser is essential. Though no version of Boost.Spirit (Spirit 2 or Spirit X3) suffers from all those limitations, there also does not exist any one version that avoids all of them. Boost.Parser does so. However, there are a lot of great ideas in Boost.Spirit that have been retained in Boost.Parser. Both libraries: - use the same operator overloads to combine parsers; - use approximately the same set of directives to influence the parse (e.g. lexeme[]); - provide loosely-coupled rules that are separately compilable (at least for Spirit X3); and - are built around a flexible parse context object that has state added to and removed from it during the parse (again, comparing to Spirit X3). """ Zach

7 15

Re: [boost] Interest in new parsing library?
by Zach Laine 29 Dec '23

29 Dec '23

On Fri, Dec 29, 2023 at 12:40 PM Zach Laine <whatwasthataddress(a)gmail.com> wrote: > > On Fri, Dec 29, 2023 at 3:53 AM Andrzej Krzemienski <akrzemi1(a)gmail.com> wrote: > > > > > > > > czw., 28 gru 2023 o 22:05 Zach Laine via Boost <boost(a)lists.boost.org> napisał(a): > >> > >> I'm trying to gauge interest in a parsing library to replace > >> Boost.Spirit 2/Spirit X3. I'm also looking for endorsements. > >> > [snip] > > > > Hi Zach, > > Thank you for writing and sharing this library. I intend to test it on my mini-language early next year. > > That sounds useful. Please let me know how it goes. > > > For now, let me dig a bit about the high-level differences between Boost.Parser and Boost.SpiritX3. > > > > Your introduction mentions "a separate lexer" as a feature that Boost.Spirit is missing. > > How does that square with the entire section for Spirit.Lex in Boost.Spirit docs? > > No, I meant the other way around. *Boost.Parser* is missing that. > Sorry for the confusion. > > > "Boost.Parser aims to be a superset of Boost.Spirit". But Boost.Spirit is also a generator. > > Quite right! I forgot about that; this is another thing that > Boost.Parser is missing vs. Spirit. > > > You mention that "Spirit X3 has rules that do not compose well". I personally never experienced this. Is there an example somewhere that would illustrate this problem? > > The issue for me is that the attribute types generated by X3 parsers > and rules are loose. This is by design. So, say you have a parser > that parses strings, producing a range of char: > > auto p = /* ... */; > > If you then use p to parse into some std::string variable in the > middle of the parse, everything works as you'd expect. But if you use > p to parse into a different std::vector<char> variable in the middle > of the parse, that also works. This is not by itself a problem. > However, I had a problem with this semantic, because there was no way > to lock down the attribute type to a specific, concrete type. So if > at some point in the parse I had: > > auto p_p = p >> p; > > That may be used to generate a std::variant<std::string, > std::vector<char>>, a std::variant<std::vector<char>, std::string>>, > etc. These types are not interconvertible. So, If you made a mistake > somewhere in writing a semantic action or something, you get an error > stating that std::variant<std::string, std::vector<char>> is not > assignable to std::variant<std::vector<char>, std::string>> or > whatever, and figuring out where the error actually lies is very > difficult. If you have a Boost.Parser rule, it has a concrete > attribute type A, and so it always produces As. I find this much, > much easier to diagnose and debug when I make a mistake. > > > What is the recommendation of Boost.Spirit authors to the programmers that need to do parsing? Is Boost.Parser simply the newer and improved version, or do they have disjoint sets of use cases? > > I think Joel answered that above. > > > Personally, skimming through the docs, I find the feature of producing custom error and warning messages very attractive. This is what I was always missing from the parsing libraries. > > > > Thanks again for your effort. > > Thanks for taking a look! Also, I should mention that this is the > easiest library I have ever written, given its complexity. That is > true due to all the very nice design work that came before it, from > Joel, Hartmut, and others. > > Zach I somehow sent only this one reply to Andrzej only; echoing here. Sorry for the borked formatting. Zach

1 0

About weird behavior with boost.asio 1.63 on linux 2.6.15
by Scott Zhang 25 Dec '23

25 Dec '23

Dear All: I have been using boost over 10+ years. The asio library work quite well along with document. Today I get a problem: My development environment: gcc 4.7.3 OABI Linux 2.6.15 boost 1.63 The code looks like below: void myTask(const char *text) { sleep(5); /*for(;;) { //sleep(1); }*/ cout<<"text is "<<text<<endl; // cout<<"out"<<endl; } boost::asio::io_service ioService; ioService.post(boost::bind(myTask,"hello")); ioService.run(); I get 2 problems: 1. If I run program as above, the mytask get executed correctly, but as soon as it returns, the program get "illegal instruction", and program dies. If I call myTask directly, then everything is ok. So what's wrong with io_service.post 2. If I run ioservice within thread using threadpool.create_thread( boost::bind(&boost::asio::io_service::run, &ioService) Then after myTask executed, I get "Killed", using strace says program get SIGKILL. As the test code is so simple, I can't tell where goes wrong. I also noticed, if I don't call io_service.post, everything looks ok. And the threads, in linux ps, shows as many processes. I reread the document of asio 1.63, it says had beed tested against linux 2.4 and 2.6 kernel. so it should be ok. Please help. Thanks.

3 5

The master branch is now open for all changes
by Marshall Clow 14 Dec '23

14 Dec '23

Thanks to everyone who participated in the release! — Marshall

1 0

[release] Boost 1.84.0
by Marshall Clow 14 Dec '23

14 Dec '23

Release 1.84.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 contain two new libraries, numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.84.0> You can also download directly from: <https://boostorg.jfrog.io/artifactory/main/release/1.84.0/source> 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. -- The Boost Release Team Marshall Clow, Glen Fernandes

1 0

[Fiber] aligned_storage is deprecated
by Niall Douglas 12 Dec '23

12 Dec '23

On Boost 1.81 with clang 18 in C++ 23 mode: ``` [build] /usr/include/boost/fiber/future/detail/shared_state.hpp:160:19: warning: 'aligned_storage<4, 4>' is deprecated [-Wdeprecated-declarations] [build] 160 | typename std::aligned_storage< sizeof( R), alignof( R) >::type storage_{}; [build] | ^ [build] /usr/include/boost/fiber/future/promise.hpp:28:22: note: in instantiation of template class 'boost::fibers::detail::shared_state<int>' requested here [build] 28 | typedef typename shared_state< R >::ptr_type ptr_type; ``` It could have been fixed upstream since, I haven't checked. Niall

1 0

[release] Boost 1.84.0 Release Candidate 1 is available
by Marshall Clow 12 Dec '23

12 Dec '23

The first release candidates for the 1.84.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.84.0/source/> The SHA256 checksums are as follows: cc4b893acf645c9d4b698e9a0f08ca8846aa5d6c68275c14c3e7949c24109454 boost_1_84_0_rc1.tar.bz2 cc77eb8ed25da4d596b25e77e4dbb6c5afaac9cddd00dc9ca947b6b268cc76a4 boost_1_84_0_rc1.zip 81a4d10075731966477276c47324ecd9cac02da49899d36c48eba66e40014f25 boost_1_84_0_rc1.7z a5800f405508f5df8114558ca9855d2640a2de8f0445f051fa1c7c3383045724 boost_1_84_0_rc1.tar.gz 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 Release managers

4 4

[scope] review
by Julien Blanc 07 Dec '23

07 Dec '23

Hi, This is my review of the proposed boost scope library. * Does this library bring real benefit to C++ developers for real world use-case? Yes. Scope guards are a well-known and widely used feature, nearly every code-base has some implementation of it. The same goes for raii resource wrappers. * Do you have an application for this library? I would consider using it for new projects. It does not, however, offer significant value at the time which would justify migrating from our homebrew scope guard. Worse, it misses some guarantees that makes it less fitted (but arguably it is more generic than what we use now). * Does the API match with current best practices? The API is copied from a TS proposal, for some parts. Most of my griefs against the API also applies to the TS. While I was not fond of it at the start, i think there's a clear value in differentiating scope_success and scope_fail. The first one is allowed to throw, the second is not. This, however, is not a strong requirement, but a general advice. It thus raises the concern about why not simply giving a boolean parameter to the scope_guard handler function, and letting it act accordingly. I suggest making the noexcept-ness of scope_fail executor a strong requirement. scope_success / scope_fail are not default-constructible, although they have a valid empty state. While there's a rationale behind this (it is a bit uncommon to create a scope guard that does nothing), it is a limitation for the sake of nothing. Initializing an empty scope_exit allows scope escaping (useful when initializing the scope guard in the body of an if statement). There will always be the possiblity to do it with an optional, so it just seems that forbidding default construction has no value. To check whether a scope_xxx is active or not, one has to call the active() method. To check whether a unique_resource has a value, one has to call the allocated() method. These are additions compared to the TS. While they may be useful, the names are inconsistent, both are new, also inconsistent with what other nullable types (optional, unique_ptr, variant...) uses. While this is common practice accross the c++ standard, I would not called this *best*. This leads to problems for generic code, and proposals such as this one: https://herbsutter.com/2022/09/25/something-i-implemented-today-is-void/ . In both case, i think at least an operator bool() should be provided, because it's a more widespread and common way to check for emptiness / valid state. scope_success / fails / exit takes an additional parameter (extension over TS), which is the execution condition. scope_success executes when the condition returns false. This is unintuitive, and something i will usually get wrong. While i get the reasoning behind, i think it tells more in favor of a scope_conditional<SuccessHandler, FailureHandler> interface. I'm not sure there's a lot of use-cases for a success_only or fail_only scope guard, especially since you can release in case of success, to avoid the cost of the failure check. About this customizable failure detector, i'm not found of the idea. The default, detection of a current exception, is a sane one. And it allows us to require FailureHandler to be noexcept. That's no longer the case if you allow customizing the failure detector. I'm not sure it's worth the tradeoff, since the failure detection could always be done inside the body of a standard unconditional scope_exit. Finally, i don't get the point of set_active. Sure, it's cheap to implement, but do we really want to encourage dynamically enabling scope guards ? Disabling a scope guard makes a lot of sense, that's what you do to disable a rollback scope_guard upon successful operation. Dynamically enabling it looks more like being hostile to the reader to me. In all cases, it's possible to get this behaviour with a boolean inside the scope guard callback, so this use case is already addressed. There's no need for it to be a first-class citizen. I like the idea of the lighter, unconditional, scope_final, which is missing in the TS. * Is the scope of the library well-defined? unique_resource and scope_exit are quite different beasts. They only have in common being RAII. But that also include unique_lock, unique_ptr, and nobody thought about making them part of the same library. I think it is a mistake to mix them. unique_resource takes three template parameters, the third one being a predicate telling if the resource is valid. I understand the wish to avoid storing an extra information, when there's a possibility to do without by storing an invalid value. But to me, it looks like a more widespread problem already solved, for example by https://github.com/akrzemi1/markable . It would be far better IMHO to get markable in boost, and have unique_resource specialized for markable<X> than replicating most of its functionality into unique_resource. * Is the documentation helpful and clear? The documentation is clear enough, although i could not find some information that i think should be emphasized more (ie, what the library guarantees in terms of pre / post conditions, noexceptness, etc). I don't like the way the reference section subitems are links to the file headers descriptions, and not links to class descriptions. I'd prefer something like: Reference * template< > class scope_exit * template< > class scope_final * ... instead of the headers, for which i usually don't care (i just need to know which header i need to include, and this information is provided in the class description). There are a few examples in the documentation that can be improved. There's always room for improvement, the overall quality is good. * Did you try to use it? What problems or surprises did you encounter? How much time did you spent? I made some small experiments with it. I spent around 6-8 hours reviewing the library and writing this review. Most of the time was spent reading the documentation and checking the behaviour. No problems and no surprises so far. * What is your evaluation of the implementation? The library is big (~2,5k lines of code), given what it offers. Most of this comes from the fact that the library offers a lot of customization points, maybe too much. Others have pointed that it reimplements some standard features, for the sake of not including some headers. I don't like this choice, but I don't know what's boost policy in this regard is. In all cases, a reimplementation with a name is better than nothing. In particular, there are some static_cast<T&&> which would advantagely be replaced by a detail::forward<T>, the latter being far more readable than the former. It's a shame that compact_storage is not provided as a facility: i guess there are several similar implementation across boost. But that's not the library's fault. Outside that, the organisation is clean, and the code largely readable, given that it needs to be compatible with C++11. * What is you final evaluation of the library? My current recommandation is to CONDITIONNALY ACCEPT the library. I think the following should be adressed, but i'd note that several of these comments also applies to the TS: - scope_success and scope_fail should be unified into a single call, taking two callbacks. This will make a slightly bigger object, but if you plan on detecting exceptions then you don't mind the extra cost anyway. And it will allow to evaluate the condition only once, so that may prove a gain in several situations. - scope_success and scope_fail should not take an execution condition. Exception detection should be enough for everyone, or else you should resort to scope_exit. - the failure handler (scope_fail) should be enforced to be noexcept - scope_exit should be default constructible (released by default, equivalent to moved-from state). That does not hold for scope_final, which is not releasable. - the active / released name fiasco should be adressed. At least provide operator bool(). - set_active should be removed. This is encouraging bad practice. - unique_resource should be moved outside the library. I consider that it belongs to a separate library, and i think it has some flaws in its design that should be addressed. Finally, many thanks to Andrey for proposing this library, and for quickly replying to the questions during the review. Regards, Julien

3 5

[release] Master Branch is closed for ALL changes
by Marshall Clow 07 Dec '23

07 Dec '23

Please do not commit anything to the master branch. Other branches are always fine. The 1.84.0 release is scheduled for next Wednesday, 13-December. — Marshall

1 0

[scope] Scope review starts on November 26th
by Дмитрий Архипов 07 Dec '23

07 Dec '23

Dear Boost community. The peer review of the proposed Boost.Scope will start on 26th of November and continue until December 5th. Boost.Scope is a small library implementing utilities defined in <experimental/scope> from C++ Extensions for Library Fundamentals v3 with a few extensions. Namely, the library contains: * A number of scope guards for various use cases. * A unique resource wrapper that automatically frees the resource on destruction. * Utilities for wrapping POSIX-like file descriptors in the unique resource wrapper. You can find the source code of the library at https://github.com/Lastique/scope and read the documentation at https://lastique.github.io/scope/libs/scope/doc/html/index.html. The library is header-only and thus it is fairly easy to try it out. In addition, the library can be used with Conan and vcpkg (see its README for instructions on how to do that). Finally, there's a single header version suitable for Compiler Explorer (https://raw.githubusercontent.com/Lastique/scope/single-header/include/boos…) As the library is not domain-specific, everyone is very welcome to contribute a review either by sending it to the Boost mailing list, or me personally. In your review please state whether you recommend to reject or accept the library into Boost, and whether you suggest any conditions for acceptance. Thanks in advance for your time and effort! Dmitry Arkhipov, Staff Engineer at The C++ Alliance.

16 83

The standard library is better documented
by Niilo Huovila 07 Dec '23

07 Dec '23

By better I mean cppreference.com. There's a page for pretty much everything in the standard library. Related pages are linked. The preconditions and behavior of functions are specified. Consequentially I come to Boost only when the standard library doesn't do enough. If you are going to compete with the standard library instead of just supplementing it, you need outstanding documentation.

14 26

Master branch is now open for bug fixes
by Marshall Clow 06 Dec '23

06 Dec '23

The master branch is now open for bug fixes and documentation changes. Other changes by release manager permission, as described in https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy The next deadline: On December 6th, master closes for all changes. As always, the calendar is at https://www.boost.org/development/ — Marshall

10 23

[release] Master Branch will close for the 1.84.0 release TOMORROW
by Marshall Clow 05 Dec '23

05 Dec '23

Don’t forget your release notes, too! — Marshall

1 0

[scope] Formal review - David Sankel
by David Sankel 05 Dec '23

05 Dec '23

- What is your evaluation of the design? I'm overall happy with the design. I like the API provided and think it is useful in many scenarios. The one question I have is why unique_resource::allocated instead of a bool conversion. This is the one aspect of the API that makes me hesitate using unique_resource for things like POSIX file descriptors as .allocated() would be quite foreign for users. - What is your evaluation of the implementation? I gave the implementation only a quick glance, but it looked fine to me. - What is your evaluation of the documentation? The documentation was good. I'd suggest the front page focuses on usage examples instead of a Boost.ScopeExit comparison though. Most people reading this page won't know about ScopeExit and are trying to evaluate whether not this library will solve their problem. - What is your evaluation of the potential usefulness of the library? I think this has wide applicability. - Did you try to use the library? With what compiler? Did you have any problems? I did not attempt to use it. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent about an hour working through the documentation. - Are you knowledgeable about the problem domain? Yes And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Yes, I do.

1 0

Proposal for Inclusion of Async.MQTT5 Library in Boost
by Ivica Siladic 05 Dec '23

05 Dec '23

Dear Boost Developers, we are writing to introduce a new C++ Async.MQTT5 library that we believe would be a valuable addition to Boost. MQTT has become the de-facto standard for IoT communication, with billions of IoT devices relying on it to publish or retrieve data from the cloud. Despite its widespread use, integrating MQTT into a C++ embedded application remains a complex and error-prone task. This challenge primarily arises from the absence of a higher-level library that offers a straightforward interface for message publishing and receiving while abstracting MQTT protocol intricacies and effectively managing various corner cases inherent in MQTT implementation. The primary objective behind developing Async.MQTT5 was to address these challenges comprehensively, allowing developers to focus on the messages they need to send without concerns about underlying network connectivity issues. Async.MQTT5 is a C++20 client implementation of the MQTT 5.0 protocol, leveraging Boost Asio and Boost Spirit. It fully adheres to the Asio asynchronous model, providing comprehensive support for all forms of asynchronous completion tokens, per-operation cancellation, and custom allocators. The library is designed to work seamlessly with any ordered network transport, typically TCP, SSL/TLS over TCP, or WebSockets (secured and unsecured). Our goal with Async.MQTT5 is to offer developers a simple and clear C++ interface for sending and receiving messages using the MQTT 5.0 protocol. Emphasizing code readability was a key design principle of Async.MQTT5. For instance, tedious protocol message parsing/composing is implemented declaratively (partially utilizing Boost Spirit). Additionally, Asio composed operations are implemented using a novel, clear, and highly efficient "chaining functional operators" approach. It is worth noting that the library is already written following Boost style guidelines, and the documentation is crafted and formatted in line with Boost conventions. You can find the library at https://github.com/mireo/async-mqtt5, and the documentation is available at https://spacetime.mireo.com/async-mqtt5/. We highly value your opinion and would appreciate any feedback you can provide on the Async.MQTT5 library. Thank you for your time and consideration. Best regards, Ivica Siladic Bruno Iljazovic Korina Simicevic

9 15

[scope] A few questions
by Julien Blanc 05 Dec '23

05 Dec '23

Hi, I have a few questions regarding the scope library currently being reviewed: * scope_exit is not default constructible. But it can be released and is movable, so a default constructed scope_exit state makes sense (this is the same as a moved-from scope_exit). I find this a rather strange design choice. What is the rationale behind this? There's even a section on the documentation on how to circumvent this: https://lastique.github.io/scope/libs/scope/doc/html/scope/scope_guards.htm… using cleanup_func_t = std::function< void() >; // Create an inactive scope guard first, since the cleanup function is not set yet boost::scope::scope_exit< cleanup_func_t > cleanup(cleanup_func_t(), false); Why can't i just write? boost::scope::scope_exit< std::function< void() > > cleanup; * the documentation says little about memory allocation. I finally found the answer i was looking for in the boost.ScopeExit comparison: scope_xxx objects do not do any heap allocations themselves. Is that a guarantee of the library? Such a guarantee is needed in some code i work with, i need to know if it is a feature of the library that i can rely upon, and not just an optimization that could go away in a further release. * unique_fd is a resource wrapper for files. But on all major systems, closing a file can fail and return an error. It may well be that the file is not completly written correctly, and this is reported not in the write call, but in the final close call. unique_fd silently drops the return value of close. I'm not sure we should encourage this behaviour. Another issue raises when we look at the example code: void write_string(std::string const& filename, std::string const& str) { // Create a unique resource for a file boost::scope::unique_resource< int, fd_deleter > file(open(filename.c_str(), O_CREAT | O_WRONLY)); if (file.get() < 0) { int err = errno; throw std::system_error(err, std::generic_category(), "Failed to open file " + filename); } // Use it to write data to the file const char* p = str.data(); std::size_t size_left = str.size(); while (size_left > 0) { ssize_t written = write(file.get(), p, size_left); if (written < 0) { int err = errno; if (err == EINTR) continue; throw std::system_error(err, std::generic_category(), "Failed to write data"); } p += written; size_left -= written; } } In case of a failure, what we got is an half-baked file, which we know nothing about. A proper write_string function should at least try to do its cleanup and delete the file in case of error. But that defeats the purpose of unique_resource... In my experience, automatically closing file handles is not error handling. But it has its use cases, maybe it would be better demonstrated by an example like: bool compare_files(std::string const& filename1, std::string const& filename2) { boost::scope::unique_resource< int, fd_deleter > file1(open(filename.c_str(), O_CREAT | O_WRONLY)); if (file1.get() < 0) { int err = errno; throw std::system_error(err, std::generic_category(), "Failed to open file " + filename1); } boost::scope::unique_resource< int, fd_deleter > file2(open(filename.c_str(), O_CREAT | O_WRONLY)); if (file2.get() < 0) { int err = errno; throw std::system_error(err, std::generic_category(), "Failed to open file " + filename2); } // do the comparison } Regards, Julien

2 7

[scope] Mr. Docs rendered reference
by Krystian Stasiowski 05 Dec '23

05 Dec '23

Hi everyone, My name is Krystian, and I'm a Staff Engineer at The C++ Alliance. I’ve been working on Mr. Docs, a clang based C++ documentation generator intended to serve as an alternative to Doxygen. Although Mr. Docs is not yet ready for release, I noticed that there was an issue with rendering the exception specification of destructors due to a bug in Boostbook. Thus, I would like to present Mr. Docs as a potential future alternative, and have generated a multi-page reference for Boost.Scope to demonstrate its capabilities: https://mrdocs.com/demos/develop/boost-scope/multi/adoc-asciidoc/boost/scop… The output was created using the built-in Asciidoc generator and converted to HTML with asciidoctor. Since the Asciidoc generator uses handlebars templates to format the output, customizing the rendered documentation is a matter of modifying the templates. Unlike Doxygen, Mr. Docs operates directly on the clang AST. This means that support for new/obscure language features is only limited by the extent of clang’s conformance to the latest C++ standard. Any feedback is greatly appreciated. 🙂 Best, Krystian Stasiowski

5 6

Re: [boost] The standard library is better documented
by Niilo Huovila 05 Dec '23

05 Dec '23

On 12/5/23 1:43 AM, boost-request(a)lists.boost.org wrote: > Date: Mon, 4 Dec 2023 12:36:27 > -0800 From: Marshall Clow <mclow.lists(a)gmail.com> To: > boost(a)lists.boost.org Subject: Re: [boost] The standard library is > better documented Message-ID: > <B135B251-3578-40CA-A9D8-34E165EE6C14(a)gmail.com> Content-Type: > text/plain; charset=utf-8 On Dec 4, 2023, at 12:21 PM, Mateusz Loskot > via Boost <boost(a)lists.boost.org> wrote: >> On Mon, 4 Dec 2023 at 21:05, Niilo Huovila via Boost >> <boost(a)lists.boost.org <mailto:boost@lists.boost.org>> wrote: >>> On 12/4/23 4:36 PM, Hans Dembinski wrote: >>>>> On 2. Dec 2023, at 16:57, Ren? Ferdinand Rivera Morell via Boost<boost(a)lists.boost.org> wrote: >>>>> >>>>> It would be useful if you could point to instances of Boost libraries >>>>> that could use better documentation. >>>> Can we organise a user poll that ranks all Boost libraries on how well documented they are? >>>> >>>> Might be a fun way to approach this and it provides an opportunity to create some publicity for Boost when we advertise this. I can see the news headline: "Boost devs finally respond to user cries for better docs" >>> The secret of cppreference seems to be that it is a wiki. How about >>> that? Users could put their energy to improving the docs instead of >>> complaining. :) >> Users can already do that by submitting pull requests on GitHub. > Or, if they don?t grok Quickbook, they can open a GitHub issue and suggest better wording. They seem relatively heavy-handed ways to add a link or correct spelling. > Date: Tue, 5 Dec 2023 00:12:17 +0300 > From: Andrey Semashev<andrey.semashev(a)gmail.com> > To:boost@lists.boost.org > Subject: Re: [boost] The standard library is better documented > Message-ID:<9e217656-9b05-4e82-a5a3-67c55d949b4f(a)gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 12/4/23 20:53, Niilo Huovila via Boost wrote: >> On 12/4/23 4:36 PM, Hans Dembinski wrote: >>>> On 2. Dec 2023, at 16:57, Ren? Ferdinand Rivera Morell via Boost >>>> <boost(a)lists.boost.org> wrote: >>>> >>>> It would be useful if you could point to instances of Boost libraries >>>> that could use better documentation. >>> Can we organise a user poll that ranks all Boost libraries on how well >>> documented they are? >>> >>> Might be a fun way to approach this and it provides an opportunity to >>> create some publicity for Boost when we advertise this. I can see the >>> news headline: "Boost devs finally respond to user cries for better docs" >> The secret of cppreference seems to be that it is a wiki. How about >> that? Users could put their energy to improving the docs instead of >> complaining. :) > Wiki is prone to vandalism and edit wars. > > Also, aside from stylistic and wording edits, the documentation is > supposed to be written by people who are very knowledgeable in the > subject. Those people are likely very few, often maintainers only. > > Wiki is good for "public knowledge" kind of documentation. The official > library documentation is very different from that. In fact, it is the > ground truth upon which that public knowledge is built. Would separating the reference from other documentation also separate it from those concerns? Then it could be a wiki and editing the other stuff can be restricted to maintainers.

1 0

[scope] some more thoughts
by Andrzej Krzemienski 04 Dec '23

04 Dec '23

Hi Everyone, I want to share some thoughts regarding the review of Boost.Scope. The fact that it wants to implement 1-to-1 a feature from a TS -- not from the standard -- impedes the review process. The reviewer says, "this feature is bad". The author responds, "but this is how the TS requires it to be". And now what? Should we accept a bad feature because the TS requires so? Being TS-conformant is very constraining for the author. Maybe this is not a worthy goal. Also, my observation from recent years is that putting stuff into a TS may be a polite way of saying, "we respect you, but we do not want this." Also, the goal of having an implementation for a proposed feature is to check if the interface has been battle-tested to be sound. The Boost Review process is such a test. When the feedback is, this feature is wrong, then this feedback should affect the STD proposal. But Boost shouldn't be compromised by an STD proposal that was submitted without a battle-tested implementation. The move assignment operator in scope_exit and friends. It looks like its existence is against the goal of the feature. You define a guard and then you use it. Why would you assign a different guard to it? Why do we have scope_success? An alternative to using scope success is to just put your instructions at the end of the function. Do you have multiple return statements in your function and at the same time you need the same sequence of operations to be performed at each end? This is a good motivation to restructure your function to have a single return. Multiple returns are generally OK, but needing the same sequence warrants a single return. scope_success seems like a solution that is looking for a problem. "But the TS has scope_success" -- this is not a good argument for me. In Boost Review we should be evaluating a library based on its own merit, not based on a similarity with some other design, which can have its own flaws. Mixing unique_resource with scope guards is not a good idea. The STD tends to use big aggregate headers. Boost does not. The solution from the TS should not be ported 1-to-1 to Boost. Boost.Scope offers at least three ways to do the same thing. For instance, to execute some code only upon some inconvenient condition, I can use scope_fail with my condition, or scope_exit with my condition, or I can add set_active on top of either. I consider this to be a bad design. Source code is not only for the flexibility of writing, but also for the ease of reading and learning. Having multiple ways to do the same thing impedes the understanding of the code. While I understand the existence of the triplet `scope_exit`, `scope_fail` and `scope_success` (D uses an analogous triplet), it takes a while to understand the difference between scope_exit and scope_final. And the choice of name doesn't help there. The Standard library chose to use term guard (std::lock_guard) to indicate something small and cheap. Maybe use this name instead. Not perfect either, but at least consistent with what we have in STD. Also, my experience is that one uses scope guards only in rare situations where you need to satisfy complex guarantees, like maintaining the same size of two vectors. And in those situations one is already very cautious, and tries to structure the code for the minimum surprises. One does not use multiple returns or complex control flows. The justification I heard for so many features in Boost.Scope is that there may be complex situations that require it. I think that in these situations restructuring the code is better than adding more features to Boost.Scope. This looks like a lot of harsh words, but I find a subset of the library very useful: * the unconditional execution of the function * the execution based on manual deactivation (active being the initial state) * execution based on the uncaught exception count, with the caveat that it sometimes doesn't work, and it is not cheap. Regards, &rzej;

2 5

[scope] unique_resource vs unique_ptr
by Bruno Martínez 04 Dec '23

04 Dec '23

Hi, unique_ptr can emulate unique_resource: template<auto nullvalue, auto delete_> class unique { using T = decltype(nullvalue); struct generic_delete { class pointer { T t; public: pointer(T t) : t(t) {} pointer(std::nullptr_t = nullptr) : t(nullvalue) { } explicit operator bool() { return t != nullvalue; } friend bool operator ==(pointer lhs, pointer rhs) { return lhs.t == rhs.t; } friend bool operator !=(pointer lhs, pointer rhs) { return lhs.t != rhs.t; } operator T() { return t; } }; void operator()(T p) { delete_(p); } }; public: using type = std::unique_ptr<struct not_used, generic_delete>; }; int main() { using unique_fd = unique<-1, close>::type; static_assert(sizeof(unique_fd) == sizeof(int), "bloated unique_fd"); unique_fd fd1(open("fd.txt", O_WRONLY | O_CREAT | O_TRUNC)); write(fd1.get(), "hello\n", 6); } The std papers say While std::unique_ptr can be tweaked by using a custom deleter type to almost a perfect handler for resources, it is awkward to use for handle types that are not pointers. But what's the awkwardness? Kind regards, Bruno

3 2

Re: [boost] The standard library is better documented
by Niilo Huovila 03 Dec '23

03 Dec '23

On 12/3/23 3:37 AM, boost-request(a)lists.boost.org wrote: > Date: Sat, 2 Dec 2023 17:44:05 +0100 > From: Andrzej Krzemienski <akrzemi1(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] The standard library is better documented > Message-ID: > <CAOenAXhr9fu6jo7PoFC6JTKBhD7Kdw6yxWJUEFxtcPgYkujHwQ(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > sob., 2 gru 2023 o 17:21 Andrey Semashev via Boost <boost(a)lists.boost.org> > napisa?(a): > >> On 12/2/23 03:35, Niilo Huovila via Boost wrote: >>> By better I mean cppreference.com. There's a page for pretty much >>> everything in the standard library. Related pages are linked. The >>> preconditions and behavior of functions are specified. Consequentially I >>> come to Boost only when the standard library doesn't do enough. If you >>> are going to compete with the standard library instead of just >>> supplementing it, you need outstanding documentation. >> >> To be fair, as useful as cppreference.com is, it is not quite the same >> kind of documentation as Boost documentation is. It is mostly similar to >> the reference section that you can find in most libraries' docs, as it >> basically translates the standard wording to human language and gives a >> single usage example in the end. There is no rationale, discussion, or >> usage recommendations. It's a feature: there's a time for discussion and rationale, but not when I just want to look up something quickly. >> The unquestionable advantage of cppreference.com is that it has lots of >> cross-links, which makes it very easy to navigate and find what you're >> looking for. Cross-linking is definitely something that Boost docs could >> use more. ^ This. The easy to navigate reference is what I miss the most. Cppreference can be explored like a retailer's magazine. Items are usually sorted to categories. It makes them more discoverable. > True, but for that we would have to have a uniform documentation experience > for all the libraries. And I do not think we are ever going to get there. I agree that it's a daunting task. Actually I thought that the first reaction to my message would be pondering whether competing with the standard library is worth the effort or even feasible. I were surprised when the first reaction was asking which docs need improvement, because cppreference sets the bar so high.

1 0

Re: [boost] [scope] Scope review starts on November 26th
by Janko Dedic 02 Dec '23

02 Dec '23

Thanks for proposing this library. Scope guards are a natural and much needed addition to Boost. The following is my review of the proposed Boost.Scope. The first thing I looked for in this library was a convenience SCOPE_EXIT { ... }; macro that would provide the functionality in the form of a control flow construct. I've managed to quickly find it, but it wasn't exactly what I was expecting. BOOST_SCOPE_FINAL [] { std::cout << "Hello world!" << std::endl; }; I found it rather odd that the capture list is not included in the macro. I looked a bit further into the documentation to find this: BOOST_SCOPE_FINAL std::ref(cleanup_func); Is this use case the reason why the capture list is required? It seems like a very rare one that shouldn't pessimize the interface for 99% of use cases. Performance shouldn't be a concern because the compiler sees all this code and inlines it anyway. In my view, this just makes the interface worse and less pleasant to use. scope_success doesn't seem terribly useful. I have yet to see a legitimate use case of this type. I haven't found a motivating example in the documentation. There should either be one, or this type should be removed from the library. There is no BOOST_SCOPE_FAIL macro. Why is it missing? I found the scope_fail example pretty bad: class collection { std::set< std::shared_ptr< object > > objects; public: void add_object(std::shared_ptr< object > const& obj) { // Create a deactivated scope guard initially std::set< std::shared_ptr< object > >::iterator it; boost::scope::scope_fail rollback_guard{[&, this] { objects.erase(it); }, false}; bool inserted; std::tie(it, inserted) = objects.insert(obj); if (inserted) { // Activate rollback guard rollback_guard.set_active(true); } obj->on_added_to_collection(*this); } }; It could be simply rewritten to not use set_active (which should be discouraged, because it makes code less declarative and harder to follow): class collection { std::set< std::shared_ptr< object > > objects; public: void add_object(std::shared_ptr< object > const& obj) { // Create a deactivated scope guard initially std::set< std::shared_ptr< object > >::iterator it; bool inserted; std::tie(it, inserted) = objects.insert(obj); if (inserted) { boost::scope::scope_fail rollback_guard{[&, this] { objects.erase(it); }}; obj->on_added_to_collection(*this); } } }; Could be made even cleaner by using an early return: if (!inserted) return; All destructor declarations in the documentation lack noexcept specification, which by default means that they're noexcept, but they're actually not if you look at the Throws section, or the implementation. Also, the question presents itself: why are these destructors allowed to throw? I feel like it is common knowledge today that destructors should not throw, and this is heavily frowned upon. I can see the want to "be generic" here, but I don't see why a library should entertain broken code. I also noticed that certain scope guards are move constructible. Why? I cannot imagine myself ever approving of someone moving a scope guard on code review. Scope guards are to be used exclusively as local variables and don't need to be moved. This just opens up room for misuse. I don't see any compelling use cases for scope_exit::set_active in the documentation. The only example I find motivating is this one: void push_back(int x, std::vector<int>& vec1, std::vector<int>& vec2) { vec1.push_back(x); // Revert vec1 modification on failure boost::scope::scope_exit rollback_guard{[&] { vec1.pop_back(); }}; vec2.push_back(x); // Commit vec1 modification rollback_guard.set_active(false); } This could as well have used rollback_guard.release();. This matches my personal experience: only dismiss/release/cancel is necessary for real use cases ("commiting" something and thus disabling the "rollback" action). absl::Cleanup for example, supports only Cancel(). There is value in preventing users from shooting themselves in the foot. I don't like the name scope_exit::release personally. I feel like "dismiss" or "cancel" would be much better. I know that std::experimental::scope_exit calls it "release", but we shouldn't appeal to false authority. I did not like the locked_write_string example. Reading this code locally: // Lock the file while (flock(fd, LOCK_EX) < 0) { err = errno; if (err != EINTR) return; } it's hard to get what's happening, why we're setting err and how big of an impact that has on function behavior. A better way to write this code would be to simply extract this piece into its own function: err = errno; if (err != EINTR) return; together with the ec = std::error_code(err, std::generic_category()), which doesn't require a scope guard. fd_deleter and unique_fd provide some nice handling for EINTR, which wasn't required but I think it's nice to have and it's good that it's a part of this library! I think make_unique_resource_checked approaches the problem from the wrong direction. This code: // Create a unique resource for a file auto file = boost::scope::make_unique_resource_checked( open(filename.c_str(), O_CREAT | O_WRONLY) -1, fd_deleter()); if (!file.allocated()) { int err = errno; throw std::system_error(err, std::generic_category(), "Failed to open file " + filename); } could be this: // Create a unique resource for a file int file = open(filename.c_str(), O_CREAT | O_WRONLY); boost::scope::scope_final close_file(fd_deleter{}); if (file != -1) { int err = errno; throw std::system_error(err, std::generic_category(), "Failed to open file " + filename); } This has the advantage of being able to use `file` directly for the rest of the code instead of `file.get()`. I think a similar utility would be more useful in form of a class template, for example: resource<HANDLE, INVALID_HANDLE_VALUE, ::CloseHandle> windows_handle; resource<SDL_Window*, nullptr, ::SDL_DestroyWindow> sdl_window_handle; This would be very useful for concisely implementing RAII wrappers over C handles (you don't have to manually write destructors, move constructors and move assignment operators). For local use (within a function), I feel like a local handle + scope guard is just more ergonomic than the whole make_unique_resource_checked thing. My overall impression is that this library is trying to be too generic when it's not really necessary. There's definitely useful stuff here that I want to see included, but also a lot of stuff that is too much. I don't personally see the need for any scope guard beyond scope_exit with a release. That covers all the use cases I've ran into very nicely. scope_fail can be more error-prone since the "commit" is not explicit, so you may end up doing rollback even when it's unnecessary. Using the modified example from the documentation: void push_back(int x, std::vector<int>& vec1, std::vector<int>& vec2) { vec1.push_back(x); // Revert vec1 modification on failure boost::scope::scope_fail rollback_guard{[&] { vec1.pop_back(); }}; vec2.push_back(x); do_something_else(); // if this throws, rollback_guard runs } If you use scope_exit with an explicit release, it's clearer IMO: void push_back(int x, std::vector<int>& vec1, std::vector<int>& vec2) { vec1.push_back(x); // Revert vec1 modification on failure boost::scope::scope_exit rollback_guard{[&] { vec1.pop_back(); }}; vec2.push_back(x); rollback_guard.release(); // commit do_something_else(); // if this throws, rollback_guard won't run } The documentation states that "exception_checker is incompatible with C++20 coroutines", which is true in general, but it doesn't have to be (depending on the coroutine library implementation). However, I bring this up because using scope_exit+release is an entirely viable alternative for coroutines. scope_exit+release will work whether you use exceptions, error codes, std::expected, coroutines or all of them combined. This is the beauty of it, which makes me feel like scope_fail is unnecessary. I vote to ACCEPT this library with the following CONDITIONS: - BOOST_SCOPE_FINAL includes the lambda capture list OR another macro that does is provided; - noexcept specification on destructors is properly documented; - move constructors on all scope guard types are deleted; - a motivating example for scope_success is provided, or the type is removed. These are my conditions, but I'm hoping the full review is taken as a recommendation in improving the library and the documentation. Best regards, Janko Dedic

3 18

[scope] The comparison with Boost.ScopeExit is unfair
by Andrzej Krzemienski 02 Dec '23

02 Dec '23

Hi All, This is not a review yet. I am just looking at the front page of the docs, and I think the comparison with Boost.ScopeGuard is unfair. You are comparing C++03 Boost.ScopeGuard with C++11 Boost.Scope. Try comparing it with C++03 Boost.Scope. Otherwise compare C++11 to C++11, and there Boost.ScopeGuard has a nicer syntax: int compute() { // Reset variables on return BOOST_SCOPE_EXIT(this_) { this_->x = 0; this_->y = 0; }; return x + y; } Regarding the example with exceptions, nobody would use Boost.ScopeGuard like this. A robust usage is in Boost.ScopeGuard's docs: void world::add_person(person const& a_person) { bool commit = false; persons_.push_back(a_person); // (1) direct action // Following block is executed when the enclosing scope exits. BOOST_SCOPE_EXIT(&commit, &persons_) { if(!commit) persons_.pop_back(); // (2) rollback action }; // ... // (3) other operations commit = true; // (4) disable rollback actions } Which is longer, but usable in coroutines. Whereas Boost.Scope's solution is not usable in coroutines. Only after these changes are applied, I think is the comparison fair. Regards, &rzej;

2 5

Boost Culture
by Vinnie Falco 02 Dec '23

02 Dec '23

It occurs to me that newcomers to the mailing list will not have any understanding of Boost culture or its development process. For example there is a recurring theme where a new person will ask about "what documentation toolchain does Boost use." The answer of course is that every library has considerable autonomy to define how it wants to generate its documents. The only requirement is that the final result is rendered as HTML. Another example is the idea that there is a "CEO of Boost." Or rather that there are particular individuals who have some sort of decision-making authority for the entire libraries. Or another example, why we use mailing lists over dedicated forum software. We might consider putting together a document which centralizes all of the collected wisdom and knowledge about Boost culture including the history of its evolution and why some things are the way that they are. This would facilitate the entry of newcomers to places like the mailing list which assume that participants already know a lot about Boost culture. This could become a chapter in the new Contributor Guide: https://www.preview.boost.org/doc/contributor-guide/index.html Thanks

4 3

Dead Link
by Brian Salehi 01 Dec '23

01 Dec '23

There is a dead link on page [Machine Learning](https://www.preview.boost.org/doc/user-guide/task-machine-learnin… refering to Boost.uBLAS library. I guess the typo is an extra s letter after /doc which seems to point to the correct page when removed. Regards, Brian

1 0

[scope] Scope review starts on November 26th
by Claudio DeSouza 28 Nov '23

28 Nov '23

It would be helpful if the cmake build was fixed to not require some specific custom setup that was used by the author during development. The cmake list file seems to check for the existence of a cmake test file, to decide whether or not to build the tests. These files seem to have been moved outside reach of the setup in place, under test/test_cmake. Also, it would be better to get rid of this: add_subdirectory(../../../.. "${CMAKE_CURRENT_BINARY_DIR}/boost_superproject") Ideally, these cmake tests should assume scope is a submodule, or a subfolder, of the boost super project. Claudio.

4 3

[release] Boost 1.84.0 beta 1 released
by Marshall Clow 24 Nov '23

24 Nov '23

Boost release 1.84.0 beta 1 is now available at: https://boostorg.jfrog.io/artifactory/main/beta/1.84.0.beta1/source/ The SHA256 checksums are: 224d595cc666c19b91214c5e9cced3988d08063146dfad9f616c481d52626f27 boost_1_84_0_b1.zip de9b35e232e4b1769f4d800ec01255a9c2546639be43e45b16ce6d109c088e99 boost_1_84_0_b1.tar.gz f8a9f21580961536a95fb7fcf9deebde45d7e0e94ddd81402f1e37ae2c590410 boost_1_84_0_b1.tar.bz2 3e4765c41974c763b7d4a67a432569bf75d3367d7a6b72c4ac9458e5004c59dc boost_1_84_0_b1.7z Release notes (still need updates): https://www.boost.org/users/history/version_1_84_0.html Please try the beta and report any problems you encounter. Thanks to everyone who contributed to the release. -- Boost Release Team

3 3

cobalt build is failing
by Alain O' Miniussi 24 Nov '23

24 Nov '23

Hi, The colbalt build fails on master, starting with this message: [...]/boost/libs/cobalt/test/main.cpp:10:21: error: too few arguments to function call, expected 2, have 1 boost::cobalt::main co_main(int argc, char *argv[]) ^~~~~~~ I can provide more details if needed, but first I'd like to know if this is expected. Thanks ---- Alain Miniussi DSI, Pôles Calcul et Genie Log. Observatoire de la Côte d'Azur Tél. : +33609650665

2 2

[1.84][beast] Permission to merge to master
by Mohammad Nejati [ashtum] 17 Nov '23

17 Nov '23

Hi, I’d like to merge this to master: https://github.com/boostorg/beast/compare/master...develop Fixes a narrowing conversion error reported in this issue: https://github.com/boostorg/beast/issues/2766 Thanks, Mohammad Nejati

2 1

[release] Boost 1.84.0 Beta 1 Release Candidate 1 is available
by Marshall Clow 17 Nov '23

17 Nov '23

Available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.84.0.beta1/source/> The SHA256 checksums are as follows: f8a9f21580961536a95fb7fcf9deebde45d7e0e94ddd81402f1e37ae2c590410 boost_1_84_0_b1_rc1.tar.bz2 224d595cc666c19b91214c5e9cced3988d08063146dfad9f616c481d52626f27 boost_1_84_0_b1_rc1.zip 3e4765c41974c763b7d4a67a432569bf75d3367d7a6b72c4ac9458e5004c59dc boost_1_84_0_b1_rc1.7z de9b35e232e4b1769f4d800ec01255a9c2546639be43e45b16ce6d109c088e99 boost_1_84_0_b1_rc1.tar.gz 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 Release Managers

11 28

Do we still want develop branch?
by Andrey Semashev 16 Nov '23

16 Nov '23

Hi, The recent case of a commit in develop that was left unmerged to master made me wondering if people still find the develop branch useful. Historically (since the SVN days), we used a separate branch for active development, which we then merged to the stable branch that was used for creating Boost releases. This allowed to test libraries together before changes propagate to the stable branch. This was useful back when the official test matrix was the primary gauge of the Boost "health", so when something broke, it was rather visible, even if the breakage manifested in downstream libraries. With the adoption of git and CI, the relevance of the test matrix has diminished, and, presumably, people have shifted towards monitoring their libraries' CI. Which means, people are less likely to notice that something broke downstream, unless the downstream developer notices and reports the problem. Although I have been that downstream developer myself quite a few times, I have to admit that this role of the develop branch of "an integration testing field" is not well filled in the current workflow. Noticing the breakage is mostly luck (i.e. a matter of me making a commit to my library and noticing the CI failure caused by an upstream dependency) rather than a rule. Additionally, I have been asked on a few occasions to avoid development directly in the develop branch and use separate feature branches instead. That is, do your commits in a feature branch, let the CI pass, then merge to develop, let the CI pass again, then merge to master. Apparently, some people are using this workflow by default to avoid breakage in develop, which means develop is no longer the branch where the actual development happens. (This workflow actually makes develop meaningless because your CI over the feature branch already tests your changes against develop of the rest of Boost. Which means after merging to develop you're running the same CI again, and might as well just merge to master straight away.) Then there's the recurring problem that led to this post - people forget to merge to master from time to time. Or simply don't have time to merge. Or the library is no longer actively maintained. Or the commit is left out of master for any other reason, which means users don't receive their bug fixes in a release. Personally, I do try to remember the PRs I make during the release cycle and look through them just before the release to make sure they are merged to master. Some of you probably received gentle merge reminders from me. I'm not sure if anyone else is doing this, but I can say this is an active mental effort on my part, which I'd rather not have to make. And even then I can't be sure I remember all PRs or have the time to cycle though them before the release. Which brings me to my question. Do people still find the develop branch useful? Maybe we'd be better off just dropping it and performing all development in feature branches before merging straight to master? Also, if you do find develop useful, what do you think about creating a GitHub Action to automatically merge develop to master once the CI on develop succeeds? Maybe there are other ideas how to avoid commits unmerged to master? Thanks.

8 51

Re: [boost] Do we still want develop branch?
by Jonathan Wakely 13 Nov '23

13 Nov '23

Oops, resending from the address that is actually sub'd the the list ... On Mon, 6 Nov 2023 at 19:13, Jonathan Wakely wrote: > > > On Mon, 6 Nov 2023 at 16:45, Robert Ramey via Boost <boost(a)lists.boost.org> > wrote: > >> On 11/6/23 1:45 AM, Alexander Grund via Boost wrote: >> > I agree here that this is a major issue and maybe the release managers >> > can check (e.g. with Peters script) for that common issue and maybe >> even >> > initiate merges. >> >> Seems to me it would be easy to make a script which the release manager >> would run before release which would flag all libraries which have >> unmerged changes on the development branch dated before the current >> date. This might resolve the whole issue. >> >> > That would imply a rule of thumb that develop should (in general) have no > changes that aren't merged to master ready for a release. > > If you're going to have such a rule, you might as well just get rid of the > two branch model and just use a trunk-based git workflow. So you work on > develop, and then at some point you create a release branch from develop, > call it boost_1_84_0 and that release branch is used for the release. No > manual merging from develop to master, because the release branch comes > straight from develop, not from an unrelated branch which should (in > theory, if the maintainer remembers) match the *content* of develop, but > not the actual history of develop. > > > > https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-… > https://www.toptal.com/software/trunk-based-development-git-flow > https://trunkbaseddevelopment.com/ > >

7 14

[Release] Master branch is closed for beta
by Marshall Clow 09 Nov '23

09 Nov '23

Master is closed for all changes. See the release schedule at: https://www.boost.org/development/index.html -- Release managers

1 0

Re: [boost] [boost.cobalt] A precondition or an error condition?
by Andrzej Krzemienski 09 Nov '23

09 Nov '23

czw., 9 lis 2023 o 17:32 Klemens Morgenstern < klemensdavidmorgenstern(a)gmail.com> napisał(a): > > Actually, your explanation convinces me even stronger that this should > be a different function with a different name. It is a different use case, > it has a different signature, a different return type. > > > > How is the use case different? I got multiple awaitable and I want to > wait for one to finish. The decision of how many is either a runtime > or a compile time decision and we're discussing how to handle the > runtime error. Sounds like the same thing to me. > They have different preconditions: one requires a non-epty variadic pack. One allows promises with different result types, the other doesn't. They differ in return types: one returns a variant, the other returns a pair. So, the following code will look different in either case. Sure they share some similarities. Much like `race` and `left_race` do. But they have two different names. Regards, &rzej;

1 0

[boost.cobalt] A precondition or an error condition?
by Andrzej Krzemienski 09 Nov '23

09 Nov '23

Hi Everyone, I would like to discuss one correctness aspect of Boost.COBALT. We have this list and the Slack channel, so I am not sure which place is better. Let me do it here. In Boost.Cobalt (formerly Boost.Async) we have function cobalt::race (formerly select()) that takes a range of awaitables `p` and returns an awaitable capable on awaiting on one of the elements of `p`: https://www.boost.org/doc/libs/develop/libs/cobalt/doc/html/index.html#race… Example: ``` promise<string> talk_to_server_1(); promise<string> talk_to_server_2(); promise<string> timeout_with_default(); vector<promise<int>> servers = { talk_to_server_1(), talk_to_server_2(), timeout_with_default() }; pair<size_t, string> ans = co_await race(servers); ``` This obviously cannot work when the input range passed to `race` is empty. Boost.COBALT docs say that for this situation "Selecting an empty range will cause an exception to be thrown". But I do not think it is the right approach. The right approach would be to clearly communicate to the user of the library that this is an incorrect usage of the library: if you pass an empty range to `race` you clearly do not know what you are doing, or you simply overlooked it and planted a bug. The library should list it as a *precondition* in the docs: the passed range cannot be empty. If you do it, you cannot expect your program to work correctly. >From the perspective of the library author, you can now, for the event of passing the empty range, putt all the tools that help in debugging: * BOOST_ASSERT * insert a breakpoint And on the next line, you can also throw an exception to avoid an UB. But in that case the exception would not be part of the official contract. If the docs just say "throws an exception" (as today, which I think is wrong) then the library author is not allowed to insert any debugging aids (such as BOOST_ASSERT or breaking into the debugger) because the user may be relying on the exception throw. You do not want the users to rely on the exception throw: you want to prevent the users from passing the empty range. What do others think about it? Regards, &rzej;

3 6

[release] Master branch closes for the 1.84.0 beta release TOMORROW
by Marshall Clow 08 Nov '23

08 Nov '23

Calendar here: https://www.boost.org/development/ — The release managers

3 5

Linking Problems starting with Boost 1.81
by Dennis Luehring 05 Nov '23

05 Nov '23

1.79 links with my software 1.80 links with my software 1.81 does not link 1.82 does not link 1.83 does not link Linux up to date Suse/Tumbleweed gcc 13.2.1 ./bootstrap.sh ./b2 -j16 --toolset=gcc cxxflags=-fPIC --build-dir=./_build address-model=64 architecture=x86 threading=multi --stagedir=./lib64-gcc --build-type=complete --layout=versioned --without-mpi these are the errors on linking when using 1.81 and above ld.lld: error: duplicate symbol: boost::phoenix::placeholders::uarg1 >>> defined at local_256.hpp:16 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:16) >>> Recipe_expression_validator.cpp.o:(boost::phoenix::placeholders::uarg1) in archive ../../implementation/expression_validation/libexpression_validation.a >>> defined at local_256.hpp:16 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:16) >>> parser.cpp.o:(.bss+0xF80) in archive ../../devs/expression_parser_lib/libexpression_parser_lib.a ld.lld: error: duplicate symbol: boost::phoenix::placeholders::uarg2 >>> defined at local_256.hpp:19 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:19) >>> Recipe_expression_validator.cpp.o:(boost::phoenix::placeholders::uarg2) in archive ../../implementation/expression_validation/libexpression_validation.a >>> defined at local_256.hpp:19 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:19) >>> parser.cpp.o:(.bss+0xFC0) in archive ../../devs/expression_parser_lib/libexpression_parser_lib.a ld.lld: error: duplicate symbol: boost::phoenix::placeholders::uarg3 >>> defined at local_256.hpp:22 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:22) >>> Recipe_expression_validator.cpp.o:(boost::phoenix::placeholders::uarg3) in archive ../../implementation/expression_validation/libexpression_validation.a >>> defined at local_256.hpp:22 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:22) >>> parser.cpp.o:(.bss+0x1000) in archive ../../devs/expression_parser_lib/libexpression_parser_lib.a anyone got an idea what changed between 1.80 and 1.81 to let my linking fail with the above errors the expression_parser_lib and expression_validation is my own code

4 8

Reminder: Boost 1.84.0 release cycle starting
by Marshall Clow 04 Nov '23

04 Nov '23

The deadline for “major changes” is next Wednesday, 1-Nov. The beta release will be two weeks later. As always, the release calendar is at: https://www.boost.org/development/index.html — Marshall

5 5

Boost test matrix
by Robert Ramey 04 Nov '23

04 Nov '23

I've merged my develop branch into the the master, waited some time, and reviewed the test results here: https://www.boost.org/development/tests/develop/developer/serialization.html . Given that we intend to release soon, I have a few questions: a) I don't see any windows compilers here. WTF? b) If I switch to "Release View" (upper left hand corner) I expect to see test runs for the master branch. I just get an error message. I can't see how we can think of doing a release with having these issues resolved. Robert Ramey

6 8

error on inclusion of ../boost/math/special_functions/next.hpp
by Robert Ramey 03 Nov '23

03 Nov '23

In reviewing the test matrix: https://www.boost.org/development/tests/develop/developer/serialization.html I'm getting the following error message when on a couple of my tests: > Test output: teeks99-dkr-dc6-17 - serialization - test_complex_text_archive / clang-linux-6.0~c++17 > Rev 1c12b5c15fc82f0cb6d4bd931a057fc050df8a34 / Sun, 29 Oct 2023 21:39:02 +0000 > Compile [2023-10-29 23:34:25 UTC]: fail > > > "clang++-6.0" -fvisibility-inlines-hidden -Wno-c99-extensions -std=c++17 -fPIC -m64 -pthread -O0 -fno-inline -Wall -fvisibility=hidden --target=x86_64-pc-linux -ftemplate-depth-255 -DBOOST_ALL_NO_LIB=1 -DBOOST_ARCHIVE_TEST=text_archive.hpp -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_BEAST_ALLOW_DEPRECATED -DBOOST_BEAST_SEPARATE_COMPILATION -DBOOST_COBALT_USE_STD_PMR=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LIB_DIAGNOSTIC=1 -DBOOST_SERIALIZATION_DYN_LINK=1 -DBOOST_WSERIALIZATION_DYN_LINK=1 -I".." -c -o "/var/boost/run/results/boost/bin.v2/libs/serialization/test/test_complex_text_archive.test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/test_complex.o" "../libs/serialization/test/test_complex.cpp" > > In file included from ../libs/serialization/test/test_complex.cpp:19: > In file included from ../boost/math/special_functions/next.hpp:17: > In file included from ../boost/math/special_functions/trunc.hpp:21: > In file included from ../boost/math/ccmath/ldexp.hpp:15: > In file included from ../boost/math/ccmath/abs.hpp:16: > ../boost/math/ccmath/isnan.hpp:35:29: error: no template named 'is_integral_v' in namespace 'std'; did you mean 'is_integral'? > if constexpr (!std::is_integral_v<T>) > ~~~~~^~~~~~~~~~~~~ > is_integral > /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/type_traits:289:12: note: 'is_integral' declared here > struct is_integral > ^ Looks like a minor snafu in ../boost/math/ccmath/isnan.hpp ... or not. Could someone who understands math/special functions took a look into this? On a totally separate note: I'm getting another failure on the same matrix: Test output: teeks99-dkr-dc6-17 - serialization - test_dll_simple / clang-linux-6.0~c++17 Rev 1c12b5c15fc82f0cb6d4bd931a057fc050df8a34 / Sun, 29 Oct 2023 21:39:02 +0000 Lib [2023-10-29 23:34:28 UTC]: fail See boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden where the links points to a file containing: > Test output: boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden > Rev 1c12b5c15fc82f0cb6d4bd931a057fc050df8a34 / Sun, 29 Oct 2023 21:39:02 +0000 > Compile [2023-10-29 23:34:25 UTC]: succeed > > "clang++-6.0" -fvisibility-inlines-hidden -Wno-c99-extensions -std=c++17 -fPIC -m64 -pthread -O0 -fno-inline -Wall -fvisibility=hidden --target=x86_64-pc-linux -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_BEAST_ALLOW_DEPRECATED -DBOOST_BEAST_SEPARATE_COMPILATION -DBOOST_COBALT_USE_STD_PMR=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -I".." -c -o "/var/boost/run/results/boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/dll_polymorphic_derived2.o" "../libs/serialization/test/dll_polymorphic_derived2.cpp" > > In file included from ../libs/serialization/test/dll_polymorphic_derived2.cpp:13: > In file included from ../libs/serialization/test/polymorphic_derived2.cpp:15: > ../libs/serialization/test/polymorphic_base.hpp:29:13: warning: polymorphic_base imported [-W#pragma-messages] > #pragma message ("polymorphic_base imported") > ^ > In file included from ../libs/serialization/test/dll_polymorphic_derived2.cpp:13: > In file included from ../libs/serialization/test/polymorphic_derived2.cpp:16: > ../libs/serialization/test/polymorphic_derived2.hpp:32:13: warning: polymorphic_derived2 exported [-W#pragma-messages] > #pragma message ("polymorphic_derived2 exported") > ^ > 2 warnings generated. > > Link [2023-10-29 23:34:25 UTC]: succeed > > > "clang++-6.0" -o "/var/boost/run/results/boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/libdll_polymorphic_derived2.so.1.84.0" -Wl,-soname -Wl,"libdll_polymorphic_derived2.so.1.84.0" -shared -Wl,--start-group "/var/boost/run/results/boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/dll_polymorphic_derived2.o" "/var/boost/run/results/boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/libdll_polymorphic_base.so.1.84.0" "/var/boost/run/results/boost/bin.v2/libs/serialization/build/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/libboost_serialization.so.1.84.0" "/var/boost/run/results/boost/bin.v2/libs/filesystem/build/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/libboost_filesystem.so.1.84.0" -Wl,-Bstatic -Wl,-Bdynamic -lrt -Wl,--end-group -fPIC -m64 -pthread -fvisibility=hidden -fvisibility-inlines-hidden --target=x86_64-pc-linux So .... This parts builds a dll/shared library which is used in the test. There doesn't seem to be anything wrong with this. Does anyone have any ideas? Robert Ramey

3 3

Boost Security Disclosure
by Feuer, Mark 02 Nov '23

02 Nov '23

Is there a written security disclosure policy for Boost? As an example, is there a boost document that says all security vulnerabilities will be reported to NIST? If so, can someone point me to the disclosure form? I've seen in some documentation references to CVEs. Does this mean all security vulnerabilities are required to be submitted to NIST? Thanks, Mark [CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this email is proprietary to Medtronic and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please delete this mail from your records. To view this notice in other languages you can either select the following link or manually copy and paste the link into the address bar of a web browser: http://emaildisclaimer.medtronic.com

1 0

[release] Master Branch is closed for major code changes
by Marshall Clow 02 Nov '23

02 Nov '23

The master branch closed for major code changes. Still open for serious problem fixes and docs changes without release manager review. The master branch will close for the 1.84.0 beta release next Wednesday As always, the calendar is available at: https://www.boost.org/development/ — The release managers

1 0

[Release] Boost 1.84.0 closing for major changes TOMORROW
by Marshall Clow 31 Oct '23

31 Oct '23

Release closed for major code changes. Still open for serious problem fixes and docs changes without release manager review. See: https://www.boost.org/development/index.html — Marshall

1 0

[scope] Looking for endorsements and review manager
by Andrey Semashev 31 Oct '23

31 Oct '23

Hi, This is a reminder that Boost.Scope is looking for endorsements and a review manager. Following is an excerpt from the previous announcement, describing the library. Boost.Scope is a small library implementing utilities defined in <experimental/scope> from C++ Extensions for Library Fundamentals v3 with a few extensions. Namely, the library contains: * A number of scope guards for various use cases. * A unique resource wrapper that automatically frees the resource on destruction. * Utilities for wrapping POSIX-like file descriptors in the unique resource wrapper. Compared to <experimental/scope>, some notable extensions are: * A new scope_final scope guard, which is a more lightweight alternative to scope_exit. It is accompanied with the BOOST_SCOPE_FINAL macro that allows to simplify scope guard declaration syntax. * Scope guards can be activated/deactivated multiple times. * Scope guards can be created inactive initially. * Scope guard factory functions, for compatibility with C++11. * Support for optional resource traits in unique_resource wrapper, which improves usage with resources having unallocated values. * unique_resource supports swapping. * unique_resource supports dereferencing for any resource types that support dereferencing, not only pointers. * More flexible constructors for unique_resource. The library requires C++11 at the minimum and will significantly benefit from C++17. Source: https://github.com/Lastique/scope Docs: https://lastique.github.io/scope/libs/scope/doc/html/index.html The library is tested in CI and used in production in one of my projects. Thanks.

5 14

Use of boost::anys::unique_any in place of boost::any
by Bhuyan, Jyotideep 23 Oct '23

23 Oct '23

Hello, As per documentation, Boost::Any is getting deprecated, and it was suggested to use boost::anys::unique_any. I am using boost::any and boost::any_cast heavily in my application code. I am looking for some sample code for best practices on how we can replace boost::any and boost::any_cast with boost::anys::unique_any. I am using VS2022, boost v1.83, and building the code with C++17. Best Regards, Jyotideep Bhuyan (he/him) Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment. Confidential - Company Proprietary

1 0

[Looking for Feedback] - Fairness lib
by Federico Abrignani 22 Oct '23

22 Oct '23

Dear Boost Community, I am writing to seek feedback on a new C++ library that I have been developing (https://github.com/Sernior/fairness <https://github.com/Sernior/fairness>). This library, named "*Fairness*," is still a work in progress. Nonetheless, I believe that this is an opportune time to begin gathering feedback. *Fairness* is designed to provide fair synchronization primitives. While the standard C++ library offers various tools for managing concurrency, it does not provide mechanisms for handling fairness policies. To introduce the most fundamental component of my library, the "priority_mutex," I would like to share a simple example: /#include <thread>/ /#include <chrono>/ /#include <algorithm>/ /#include <BS_thread_pool.hpp>/ /#include <boost/fairness.hpp>/ / / /static boost::fairness::priority_mutex<4> pm;/ / / /static void busy_wait_nano(int64_t nanoseconds){/ /auto begin = std::chrono::steady_clock::now();/ /for(;std::chrono::duration_cast<std::chrono::nanoseconds>(std::chrono::steady_clock::now() - begin).count() < nanoseconds;)/ / continue;/ /}/ / / /static void thread_function_nano(int p, int preCriticalTime, int postCriticalTime, int criticalTime){/ / busy_wait_nano(preCriticalTime);/ / pm.lock(p);/ / busy_wait_nano(criticalTime);/ / pm.unlock();/ / busy_wait_nano(postCriticalTime);/ /}/ / / /int main()/ /{/ / std::array<int, 8> prios {0, 2, 2, 1, 1, 3, 3, 0};/ / std::array<int, 8> preCT {2000, 1500, 2000, 3000, 1000, 500, 500, 2000};/ / std::array<int, 8> postCT {5000, 3000, 2000, 2500, 1000, 1500, 1500, 4500};/ / int criticalTime = 1000;/ / / / BS::thread_pool pool(8);/ / / / for (int i = 0; i < 8; ++i){/ / pool.push_task(thread_function_nano, prios[i], preCT[i], postCT[i], criticalTime);/ / }/ / pool.wait_for_tasks();/ / / / return 0;/ /} / /// using BS thread pool https://github.com/bshoshany/thread-pool in this example./ / / In this example priorities are not given randomly, you can see that I gave 0 priority (the highest priority) to thread 0 which has 2000 + 1000 + 5000 and thread 7 which has 2000 + 1000 + 4500. Priority mutexes function much like a `std::array`, using a 0-indexed based system. For instance, a `priority_mutex<4>` will manage priorities ranging from 0 to 3, with 0 being the highest priority. Currently, the library comprises priority mutexes, both recursive and shared versions, along with RAII wrappers such as `unique_lock` and `shared_lock`, all of which support priorities. There are, however, some elements still missing, including priority condvars and timed versions of the mutexes. The primary motivation behind creating this library is to enhance throughput in multi-threaded pipelines. To illustrate the concept more simply, imagine a pipeline with N tasks, some of which access a protected resource. In cases of contention, there exists an optimal order of resource accesses that minimizes overall execution time, https://sernior.github.io/fairness/ <https://sernior.github.io/fairness/> the images show 2 different ways of ordering critical sections one of which is much better than the other. This library aims to empower developers, who have profiled their software, to manipulate this order with minimal performance overhead and as simply as possible. In terms of implementation, much of the development has revolved around benchmarking and testing. During this process, I've experimented with over 10 different versions of the priority mutex. Ultimately, I achieved the best results by using a priority spinlock, which is also available to library users, to provide internal atomicity to the rest of the mutexes. An essential consideration in the implementation is ensuring that the internal priority spinlock is 128 bytes away from the rest of the memory used by the mutex especially the memory used to perform the atomic::wait on. This separation helps avoid false sharing. The choice of 128 bytes aligns with processor architectures like AMD Zen 4 (the one I am testing on), as indicated in their optimization manual. I can attest that without those 128 byte separation the PM_LockUnlock benchmark was 10X worse and the PM_pipeline_benchmark_fast was worse than the std counterpart (see below for the benchmarks). Another aspect to note in the implementation is the use of 4 bytes for booleans when only a single byte is needed. This decision is related to the way atomic::wait is implemented. Most standard library implementations of atomic::wait check if the type size is supported by the current platform's wait syscall. For instance, Windows can wait on 1 byte, while Linuxkernel based systems can only wait on 4 bytes. These are some benchmark results: 6.4.0-kali3-amd64 AMD Ryzen 5 7600X 6-Core Processor Now the LockUnlock benchmarks were the most difficult to optimize. Those are 8 threads simply doing: m.lock(); m.unlock(); The pipeline benchmarks (with different lenght) are actual pipelines where each thread has different times before/during/after the critical section and I try to set the priorities accordingly to finish as soon as possible. You can see there is also a mutex called slim_priority_mutex, that is a priority_mutex implementation that can support up to 7 (15 if boost atomic is found and your hardware supports the DWCAS) priorities. Those are light weight versions that only take 128 bits up to 7 priorities and past that, up to 15, 256 bits. I am also testing with a custom wait implementations (https://github.com/Sernior/fairness/blob/main/include/boost/fairness/detail… <https://github.com/Sernior/fairness/blob/main/include/boost/fairness/detail…>) which can be tested by defining BOOST_FAIRNESS_USE_EXPERIMENTAL_WAIT_NOTIFY. At some point I wish to make this wait the default version the lib uses instead of the std one since users of my lib could configure this version using my configs macros (number of fast spins - relaxed spins - yield spins before the wait syscall). As I said in the beginning other than to present my lib, this email has the purpose of obtaining feedback. I would like to see if there is anyone (other than me) interested in what I am doing and, if so, consider that I am still far from finished and I would love suggestions. Thank you all for your attention. Best regards, Federico Abrignani.

3 5

[boost.async] new name
by Klemens Morgenstern 13 Oct '23

13 Oct '23

Given the renaming requirement, I'd like to query the list if there are any objections to any of the following names: async.core await co_async / cosync co20 / cor20 Thanks, Klemens

14 28

[Async] Naming land grab?
by Niall Douglas 12 Oct '23

12 Oct '23

Dear Boost, I have received a non-public review which raises concerns about the naming land grab by proposed Boost.Async i.e. a Boost library called "Async" claims too much through its name. Seeing as nobody here has raised this concern to date, can I confirm everybody here is fine with proposed Boost.Async being called Boost.Async? If you are not, please suggest a preferred alternative name. Niall

21 67

Library proposal - indexed_array
by Julien Blanc 12 Oct '23

12 Oct '23

Hi, I've written and released a (rather small) library which allows defining arrays with arbitrary index mechanisms (hence the name, indexed_array). This especially allows indexing with scoped enums, use non zero-starting indexes, or use sparse indexes. This is not a view, but an array in the sense that it owns the data, and provides the same guarantees and functionalities as std::array, such as triviality propagation, being able to reside in read-only program sections, etc. It also supports multidimensional indexing, and provides an indexed_span template class to access lower dimension content (which can be used outside indexed_array). Finally, it provides an opt-in safer way to initialize the array content, which is especially useful when using complex and/or changing indexing schemes (like based on externally generated files). The library is available here: https://github.com/Julien-Blanc-tgcm/indexed_array And the doc is here: https://julien-blanc-tgcm.github.io/indexed_array/ It requires C++17 and mp11, and has first-class support for describe-d enums. If there is some interest, i'd like to propose it for inclusion in boost. So i'm looking for people who would endorse it. Thanks and best regards, Julien

8 24

Re: [boost] Welcome to our NEW Boost Discourse server! 🥳🎉
by René Ferdinand Rivera Morell 12 Oct '23

12 Oct '23

On Wed, Oct 11, 2023 at 5:33 PM David Sankel <camior(a)gmail.com> wrote: > > On Wed, Oct 11, 2023 at 6:20 PM René Ferdinand Rivera Morell <grafikrobot(a)gmail.com> wrote: >> >> How does one start a new topic in a category through email on this? >> I.e. without using the web UI. Yes, I'm trying to use this thing. > > > It looks like this is something I needed to enable. You can try sending an email to boost+development-4(a)discoursemail.com to post to the boost development category. Why is that not a boost.org email address? Also, where do I find those email addresses? -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

2 3

[Async] Peer review report and conditions
by Niall Douglas 12 Oct '23

12 Oct '23

Dear Boost, Proposed Boost.Async by Klemens Morgenstern was reviewed between 8th and 18th August, and again between 22nd September and 2nd October. Reviews or substantially detailed comments came from: - /u/trailing_zero_count on Reddit - Ruben Perez - Marcelo Zimbres Silva - Andrzej Krzemienski - Mohammad Nejati - Janko Dedic - Robert Leahy I would like to thank those above for taking the time to write their detailed comments or reviews, and if I forgot to list anyone, please do forgive me. I did read all reviews and comments as they came in, so even if your name is not listed above, I did take into account your feedback. I would also like to thank all those far too many to list here who gave initial impressions, relaying spelling mistakes in the docs, or otherwise gave feedback of various forms. Boost could not continue without you! The tl;dr; outcome is that proposed Boost.Async is ACCEPTED but with CONDITIONS. Next follows are the **binding** conditions without which the library is not accepted: 1. The library needs to be renamed to something the Boost community doesn’t object to Quite a bit of discussion and feedback surrounded the proposed name “Boost.Async”. Multiple people felt that the name claims too much seeing as it is a C++ 20 coroutines only library, and is from first appearances entirely tied into Boost.ASIO (technically, any ASIO i/o executor can wrap any third party executor, but I can see where people get the strong ASIO association). I agree with Klemens that putting “ASIO” in the new name would be out of character with the other Boost libraries also heavily orientated around Boost.ASIO which do not have ASIO in their name. I find the suggestions that C++ 20 coroutines needs to be somehow in the name convincing. Exactly what form it should take I’ll leave up to the author and community to negotiate, but “Boost.Async” is definitely not a name with good buy-in in the Boost community. It cannot be named “Boost.Async” if it is to enter Boost. 2. The `select()` operation either needs to have its semantics changed, or be renamed Quite a few reviewers found the current semantics unpleasantly surprising, in that a random ready awaitable is chosen and all the others cancelled. This is far away from what `select()` typically means in the C and C++ worlds, and multiple reviewers commented negatively about this. The docs are unclear if it is guaranteed that the first ready awaitable is always chosen, or whether it is _some_ ready awaitable. The difference is important in many kinds of async programming. As this is a single threaded implementation, it should be possible to offer strict guarantees here. The semantics are acceptable if the operation is not called “select”, so I would suggest the easiest course here is to rename that operation to something more acceptable to the Boost community. 3. Channels need to terminate the process if relocated during use, or be made immovable, rather than it being UB to relocate them Some reviewers found the hard UB of moving a channel in use a poor design decision. Hard UB is good if it confers distinct benefits, however reviewers couldn’t see one here, and neither can I. As this library requires C++ 20 in any case, the obvious thing to do is make them immovable, but if that is felt too cumbersome, then they ought to noisily terminate the process or something not footgunny if relocated during use. Other non-binding feedback, which is not a hard condition of acceptance: - Multiple people found the naming of `promise` confusing. A promise is something in C++ land associated with a future, and I suppose in a few years it will also be associated with C++ coroutine awaitables. But here we have an awaitable named `promise`? Yes I know it makes sense in other programming languages, but here in C++ land it just seems weird and confusing for no obvious gain. I personally would suggest `eager_task` and `lazy_task` but I have no especially strong opinions on naming here other than that `promise` is a poor choice for any awaitable type. In fact, I think just don’t put the word “promise” into any awaitable type period. - I am sympathetic to multiple people raising the lack of preconditions and postconditions on operations described in the documentation. I also accept that in an async world, it’s hard to be precise. However, I think it would be a large benefit to the documentation to describe for each operation a list of the ways in which it can fail, and I think this should be added. - Andrzej took issue with the design of the generators, and I can see why. However, out in real world code land, C++ coroutine generators have surprisingly large amount of design variation. I’ve seen ones which you loop on testing them for boolean true, I’ve seen others which loop on their iterators, I’ve even seen ones which don’t implement either boolean true nor iterators and require you to call a `value()` member function which returns an Optional. Why? No idea, people seem to innovate uselessly here for some reason. I think it wise to adhere to `std::generator` from the standard, and do exactly what it does. From my reading of Async’s `generator`, whilst it has extensions e.g. the invocable call operator, the only thing missing is the iterator interface to make it implement `std::generator` and I don’t see any obvious reason why an iterator interface can’t be added here? - I agree with Andrzej about ever throwing `std::logic_error`, it should not be done in newly written code. It is recognised as a mistake by most on the standards committee nowadays. - The Mersenne Twister is a poor PRNG by modern standards. You should use JSF or anything else both much faster and higher quality. - More than one reviewer wants the docs to do a much better job on documenting pseudo-awaitables and awaitables and `await_transform`. - Quite a few times the docs talks about “async” when it really means “C++ coroutines”. - I think the docs does a poor job of disambiguating when what it is describing is part of the C++ standard, or it is part of Boost.Async. The reason this is important is that users need to know when/if they are locking themselves into Boost.Async proprietary extensions vs standard C++ coroutines. Finally, as a personal note on the review, it was notable how much negativity there currently is against C++ coroutines in general from the C++ community. A small number of us have been writing C++ coroutine code for many years now, we have been through the process of getting footgunned over lifetime issues, got frustrated that these coroutines are not the coroutines we were looking for, and eventually came round to understanding what C++ coroutines are good at solving, and more importantly what they are NOT good at solving. Once your head is wrapped around that, then comes the problem of having to reinvent a C++ coroutine support library because all the current open source ones have severe issues, especially around very tight coupling being imposed on your codebase. I don’t personally agree with every design decision in proposed Boost.Async, but I do think this will be a major step forward in making C++ coroutines accessible to many more developers than now, especially because this is to my knowledge the first standards-based loosely coupled C++ coroutines library which is open source. Undoubtedly after it ships with Boost, deficiencies will be found both in this library and in the currently quite poor quality implementation of C++ coroutines in the three major compilers. I very much hope that the increased number of developers using C++ coroutines as a result of this new Boost library will result in large and substantial improvements in implementation and library support of C++ coroutines. My thanks to Klemens for putting the work into what is a controversial and opinionated library design quite unlike any other currently available. It’s not easy to tread new ground without much precedent. My thanks to the Boost and Reddit communities for their ample and detailed review feedback, which made me managing this review possible.

5 13

Welcome to our NEW Boost Discourse server! 🥳🎉
by Inbal Levi 11 Oct '23

11 Oct '23

Hello everyone! Boost board has been working on a few improvements lately, one of which is to create a new *Boost Discourse server: https://discourse.boost.org/ <https://discourse.boost.org/>* The server is meant to allow more interactive and convenient development in the boost community, and we'll be happy to have you all there! *To join the server:* 1. Go to the URL: https://discourse.boost.org/ 2. Login to the discourse server 3. The server contains three categories: 1. Beginners - start here if you're new to Boost or to discourse 2. Boost Development - go here to create a new topic of discussion (roughly, we expect every new library will have its own discussion thread) 3. Community - go here if you'd like to start a thread about community topics, or if you'd like to talk about anything that doesn't fit the first two topics :) *To start a technical discussion:* 1. log-in 2. Go to the "*Boost Development*" category 3. Click on "+ New Topic" (in the right upper corner), and add a new discussion topic for your library! [image: image.png] Please review our Code of Conduct <https://cppnow.org/about/code_of_conduct/> before participation. We expect a respectful and positive discussion! If there are any technical issues, feel free to approach me at: sinbal2lextra(a)gmail.com or any other of the server admins: jeff(a)crystalclearsoftware.com, camior(a)gmail.com, whatwasthataddress(a)gmail.com Looking forward to seeing you all in our new discourse server! 🤗 Thanks, Inbal Levi, in the name of the Boost Foundation board members ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Lead Software Engineer @ Millenium* Isocpp, Boost &"Hamakor" Non-Profits Board Member ISO C++ LEWG Chair & Israeli NB Chair C++Now Program Chair & CoreC++ Conference Organizer ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

6 8

Mutual respect
by David Sankel 10 Oct '23

10 Oct '23

Some comments in the boost Async discussion were unconstructive and disrespectful. I want to remind folks that this is not how this community operates and thrives. Technical disagreements are, of course, fine and encouraged but we don't cross into putting people down, imputing nefarious motives, or disrespecting people's efforts. Thanks, -- David

2 1

Raising minimum target Windows version
by Andrey Semashev 08 Oct '23

08 Oct '23

Hi, I'm considering raising minimum target Windows version for my libraries to at least Windows 7. This means dropping workarounds for missing WinAPI functions that are present (but, for a very long time now, untested) for Windows XP. This specifically pertains to Boost.Atomic, Boost.Filesystem and Boost.Log. I'm also tempted to raise the requirement to Windows 8 to have access to WaitOnAddress & co., but I'm hesitant since Windows 7 might still be wide spread (perhaps, not on desktop but embedded). The current plan is to announce this in the release notes for the upcoming 1.84 release and drop the support in 1.85. This will mean the dependent libraries and tools will similarly drop support for older Windows versions. Additionally, I'm proposing to raise the default target Windows version in Boost.WinAPI to Windows 10, provided that the Windows SDK that is detected in compile time supports it. This means that by default many Boost libraries that rely on Boost.WinAPI for WinAPI definitions will target Windows 10. Which, in particular, means the prebuilt binaries we distribute will require Windows 10, unless libraries take explicit measures to stay compatible with older versions. I have no fixed time frame for the proposed Boost.WinAPI change, but it could be done as soon as in 1.84, since this doesn't remove anything, just changing the default. Comments? Objections? Counter-proposals? I'm especially interested in comments regarding Windows 7 as the new baseline - am I being too conservative? Thanks.

6 10

issue with boost::any documentation
by jepessen＠wteam.it 06 Oct '23

06 Oct '23

Hi. I was reading the online documentation for boost::any, when I went to this page: https://www.boost.org/doc/libs/1_83_0/doc/html/any/ValueType.html clicking on the next arrow will go to this page https://www.boost.org/doc/libs/1_83_0/doc/html/reference_section.html that seems a page of boost::PFR instead of boost::any. In fact, by clicking on next and previous arrows, allows navigating to PFR documentation. Im not an expert on about how documentation works, so I dont know how fix it and make a pull request. What should I do? Daniele Lupo

2 1

[Async] Review from Janko Dedic
by Niall Douglas 02 Oct '23

02 Oct '23

This was sent to me privately with an express wish it be posted here. I don't know if the author is subscribed here, so I don't know if replies will be seen. This is the first REJECT review. Niall --- cut --- What follows is my review of the proposed Boost.Async library. >Please state your experience with C++ coroutines and ASIO in your review, and how many hours you spent on the review. I have considerable experience with C++ coroutines as I've been implementing my own coroutine types in the past. I have used Asio before in a professional setting, although I wouldn't call myself an Asio expert. My experience involved using Beast/Asio to perform HTTP requests and sending fan-out notifications to external subscribers. Notably, I have a lot of experience with asynchronous programming in other programming languages, mainly Java, Kotlin and JavaScript, but I'm also very familiar with how it works in Go and Rust. I would say I've spent around 10 hours evaluating the proposed library. When I first saw this library being proposed, I was hoping it would provide a more modern, capable and ergonomic version of asynchronous programming, like other modern programming languagues and unlike Asio. The goal of this library is seemingly not to provide such an out-of-the-box seamless solution, but very specifically to provide certain coroutine-related utilities and enable composition of different coroutine types, including user-defined coroutine types (unlike `asio::awaitable`). However, I don't think either characterization is entirely correct, and Boost.Async finds itself in an awkward middle. On one hand, it does not build on top of Asio to provide a modern and seamless experience which would completely replace the direct usage of Asio (which is exposed front-and-center in the interface and code using this library has to also use Asio a lot to get the job done). On the other hand, it's also not a completely generic "coroutine library" that only provides abstractions based on C++ coroutines that could be used by any library (because it depends on Asio specifically). In my view, the correct way to characterize this library would be to regard it as a bundle of coroutine-related utilities on top of Asio. However, the library is evidently not entirely compatible with any kind of Asio usage as it's focused on "simple single threaded asynchronicity." It can certainly be used in conjunction with Asio, but it definitely brings some additional nuance and complexity (which I don't think is good, considering that Asio has a lot of complexity of its own). When it comes to added functionality, there are definitely some welcome additions in the form of `async::with` for asynchronous clean-up, `async::select`, generators. What mainly stands out to me is channels, which are a very important bread-and-butter feature for many languages. However, we should keep in mind that Asio has some experimental support for channels as well, and users of this library would probably be faced with an unnecessary choice sometime in the future. One of the most advertised features is the ability to "compose arbitrary third party awaitables without any additional effort, which lets you tie together third party libraries with ease and convenience". Firstly, I don't think this is a goal worth pursuing. As a user, I would definitely want as few coroutine types as possible in my codebase (ideally one). `asio::awaitable` already nicely fits the bill. I very well understand that we need at least a few more for sync/async generators, but that's where I'd draw the line. Secondly, this library does not exactly fulfill the promise of "tying together third-party libraries with ease". Boost.Async does not work with any coroutine library out of the box. For example, my coroutine types are incompatible with it and the code doesn't compile. Same goes for `asio::awaitable`. There is definitely some integration effort necessary to wrangle these distinct types to work together. Related to this, I also dislike exposing the whole C++ coroutine machinery as some kind of a first-class "standard" API for integrating different coroutine types together. There is evidently no "standard" API for integrating different coroutine types as arbitrary coroutine types won't simply work together out of the box. Additionally, having used the standard coroutine customization points myself, I can't say I like this API at all and I consider it a necessary evil. It is very subtle, error-prone and hard to reason about. This is definitely not something that should be exposed to the users of the library, even experts. Implementing one coroutine type is hard enough, but making sure that two coroutine types from different authors work together is even harder. Considering the complexity of the standard coroutine API, even if my coroutine types compiled with this library's types, I would not trust the whole thing to actually work in all the edge cases. I believe `asio::awaitable` made the right choice here. I have built the library and played with the examples a bit. I've tried integrating it with my own coroutine types as I've described above. The documentation is filled with examples, which is good, but the reference section is lacking a bit in a sense that it doesn't document the signature, arguments, the return type, preconditions etc. as you would expect. I don't see this is a major issue because the documentation can always be improved, and perhaps we still have to discover how to effectively document coroutines because of how unique and different they are. I vote to REJECT this library on the basis outlined above. This is definitely an admirable effort and I want to see more progress for C++ in this direction, because the standardization efforts are not promising and there are still no open-source libraries comparable to the likes of Rust's Tokio and Kotlin's standard library. Unfortunately, I don't think this library is a step in the right direction. All the best, Janko Dedic

2 1

PSA: C++11 libraries need to update their libraries.json and CMakeLists.txt
by Peter Dimov 02 Oct '23

02 Oct '23

Libraries that now require C++11, such as Atomic, TypeIndex, LexicalCast, need to update their libraries.json files to now state "cxxstd": 11, and to add the C++11 requirement to their CMakeLists.txt files, e.g. target_compile_features(boost_lexical_cast INTERFACE cxx_std_11) boostdep --cmake looks at libraries.json and automatically adds the above requirement, so for generated CMakeLists.txt files (such as the one in lexical_cast), a simple regeneration with e.g. `boostdep --cmake lexical_cast` will suffice. Note that cxx_std_11 requires CMake 3.8, so the cmake_minimum_required line may need to be adjusted as well. (`boostdep --cmake` does that automatically.)

2 4

Windows Regression Runners - Failing on Develop
by Tom Kent 02 Oct '23

02 Oct '23

Starting sometime between 3am and 5pm on September 11, 2023, all the windows regression runners started failing on the develop branch. Master branch runners on the same VM are still doing fine ( https://www.boost.org/development/tests/master/developer/summary.html) The output doesn't have anything jump out at me. Nor were there any commits to the develop branch in that window that seem suspicious to me. The regression run output ends with: ...found 1 target... # Searching for "process_jam_log.exe" in "C:\teeks99-09\run\boost_regression\stage\bin"... Traceback (most recent call last): File "run.py", line 71, in <module> runner(root) File "C:\teeks99-09\run\boost_regression_src\regression.py", line 286, in __init__ self.main() File "C:\teeks99-09\run\boost_regression_src\regression.py", line 623, in main getattr(self,action_m)() File "C:\teeks99-09\run\boost_regression_src\regression.py", line 580, in command_regression self.command_setup() File "C:\teeks99-09\run\boost_regression_src\regression.py", line 351, in command_setup self.build_if_needed(self.process_jam_log,self.pjl_toolset) File "C:\teeks99-09\run\boost_regression_src\regression.py", line 714, in build_if_needed tool[ 'build_path' ] = self.tool_path( tool ) File "C:\teeks99-09\run\boost_regression_src\regression.py", line 739, in tool_path , '\n'.join( [ name_or_spec[ 'path' ], build_dir ] ) Exception: Cannot find "process_jam_log.exe" in any of the following locations: C:\teeks99-09\run\boost_regression\stage\bin\process_jam_log.exe C:\teeks99-09\run\boost_regression\stage\bin With the full output available here: https://gist.github.com/teeks99/bb4230f6a1efdd7af11bd93341c950bf Any ideas on this would be much appreciated.

5 15

Dropping support for InPlaceFactory from Optional
by Andrzej Krzemienski 01 Oct '23

01 Oct '23

Hi Everyone, I would like to get the community's advice on removing the support for InPlaceFactory from Boost.Optional. The motivation for this is to reduce dependencies among Boost libraries. Boost.Optional is surprisingly heavy. This is mostly due to the dependency on InPlaceFactory and OptionalPointee from Boost.Utility. https://pdimov.github.io/boostdep-report/develop/module-weights.html#weight… InPlaceFactory ( https://www.boost.org/doc/libs/1_83_0/libs/utility/doc/html/utility/utiliti…) used to be a workaround for the missing "perfect forwarding" in C++03, it emulated both "universal references" and variadic templates. It is unnecessary for C++11 where Boost.optional offers a superior interface. But removing the support for InPlaceFactory would break code for people that happen to use it. When the user switches to C++11 (C++03 support is deprecated for Boost.Optional) they should expect their programs to still compile. But if I remove the InPlaceFactory, it forces the users to change their code, even if they are already on C++11. Can InPlaceFactory be moved to a separate library? Or is it so useless now that it has to be eradicated even at the cost of breaking users' code? I would welcome any suggestions. Regards, &rzej;

3 3

[boost.async] Andrzej's review
by Andrzej Krzemienski 01 Oct '23

01 Oct '23

Hi Everyone, I would like to thank Klemens for writing and sharing the Async library. It is something the community needs, and it is clear that a lot of thought and effort was put in it. I am not an expert on C++ coroutines or coroutines in general. I have played with a few echo-server examples in the past from Boost.ASIO, and created some toy examples of C++ coroutines. I devoted something like twelve evenings studying the Boost.Async: reading docs, testing toy examples (Windows 11, MSVC 2022), debugging and asking Klemens a lot of questions. Still, I cannot say I understand the library well enough to be able to responsibly give a recommendation. But I can still share my observations. On the design. Although my knowledge is superficial, I will risk a claim that the synchronization mechanisms and supporting features (`with`, channels, work_group) are the strong part of the design. (I disagree with the overload set for `select`, but I guess this is a non-design bug.) Regarding the choice and design of "coroutine types", I have certain reservations. It is still not clear to me why we have two -- promise and task -- and when I should use which. The docs give some answer: promise is eager, task can be awaited/spawned on another executor than it was created on. But is that it? I sense that there is a good reason to have them as two types, a better/clearer one than this described in the docs.But I fail to see it, and the docs do not explain it clearly enough, I think. I am uneasy about the design for `generator`. I filed a couple of issues: https://github.com/klemens-morgenstern/async/issues/101 https://github.com/klemens-morgenstern/async/issues/70 One problem is how the `generator` signals that it has finished. In all the examples it has to create a dummy value. I hear from Klemens that it is a necessity imposed by the coroutine design in C++. I do not feel competent to confirm it or not. But I note that std::generator does not require the user to `co_return` anything. And that asio::experimental::coro does allow the user to specify that they do not want to co_return even if they co_yield things. Regarding the value-returning generators, I have even more reservations. As noted in one of the quoted GitHub issues, the fact that it has a different interface than the normal generator, and that it has to be lazy to be usable, It looks to me like it qualifies for a separate coroutine type. On the documentation. The only other library offering coroutine support and any documentation that I know of is Boost.ASIO. In comparison to Boost.ASIO, Boost.Async has a waaay better documentation. It is big (in a positive sense), it has a lot of tutorial materials, lots of ideas explained, it is still being improved. It is waaay above the average quality of a library documentation that you can find on the web. But still I would greatly appreciate an even better one, however arrogant that seems. My reasoning is that for the next couple of years people who will consider Boost.Async will not only be unfamiliar with the library but also with C++ coroutines in general. They will need additional extra help to be able to use the library responsibly. To be more specific, I would expect more full compiling examples (those in folder examples) that illustrate different aspects of the library. For instance: * A convincing example of value-returning generator * timeout implemented in terms of `async::select`. I would expect a more detailed explanation of concepts used in this library: * interruption and cancellation, and how they differ, and when/if I should care about them. * being detaching and being detached, and how it is different from spawning. I got a response in one of GitHub issues that, "Interrupt is [...] meant to make select work lossless. What gets detached is the co_await itself, not the awaited thing." I feel the documentation should explain it more cleanly, and perhaps introduce some more well defined terms. The library does not cleanly communicate preconditions on the operations. I think it sometimes decides to throw an exception when a precondition is more appropriate. In other places it is silent about the corner cases. It also does not specify clearly what is guaranteed of the provided operations. Klemens correctly points out that postconditions are tricky in the case of asynchronous operations, but (1) some things in the library are not asynchronous and (2) this library (like any other) does offer some guarantees, if not on individual function calls, then for the entire expressions. For instance `co_await select(aw1, aw2)` does provide a guarantee that the result of one of the awaitables will be returned and the others will be interrupted. It should be specified in the synopsis of `select`. On the implementation. It is mostly magic to me, so I do not have much to say. There are a lot of awaitable types created whose existence I could not predict from studying the docs. I cannot say if this is a deficiency of the documentation, or is this how the C++ coroutines work: you might need a lot of awaitables that are implementation details. I find the design of the overload set of functions `select` bad and generic-programming-unfriendly. I explained it in detail in: https://github.com/klemens-morgenstern/async/issues/103 Functions that do slightly different things should have different names. Returning different types for special cases breaks generic code, and causes surprises, sometimes runtime surprises. Also, because the overload for value-returning promises returns a variant, I have run into an interesting situation when trying to add a timeout support to the echo server example. I get the following statement: ``` variant2::variant<variant2::monostate, tcp_socket> ans = co_await async::select( timer.async_wait(async::use_op), acceptor.async_accept() ); ``` And now I have a variant to unpack inside a coroutine. Normally, the recommended way to unpack a variant is to use a visitor: ``` struct visitor { void operator()(tcp_socket&& sock) { co_yield std::move(sock); // ERROR } void operator()(variant2::monostate&&) { } }; visit(visitor{}, std::move(ans)); ``` But this doesn't work, because now I am co_yield-ing from a non-coroutine. And I have to resort to manually inspecting the variant, which is taught to be error prone. I guess this is the right choice to use variant for the return type of `select`, and that it is the limitation of variant, until C++ gets pattern matching. But still, it would be helpful if the documentation (or examples) illustrated what potential difficulties the user can expect. Should the library be accepted to Boost? Again, I am not competent enough in the domain of coroutines, to responsibly say that the library meets the bar, but because I think the community desperately needs this kind of library with Boost-quality docs and support, I will risk saying that Boost.async should be conditionally accepted. The conditions being: * Address the design of generators (either change it or provide a clearer rationale) * Improve the docs - clearly describe the notions of interrupting, canceling, detaching, spawning. - provide a more detailed synopses for functions and classes with preconditions, described effects, and the guarantees. I filed this as a list of issues in the GitHub: https://github.com/klemens-morgenstern/async/issues/120 https://github.com/klemens-morgenstern/async/issues/119 https://github.com/klemens-morgenstern/async/issues/117 https://github.com/klemens-morgenstern/async/issues/115 https://github.com/klemens-morgenstern/async/issues/114 https://github.com/klemens-morgenstern/async/issues/103 https://github.com/klemens-morgenstern/async/issues/101 https://github.com/klemens-morgenstern/async/issues/100 https://github.com/klemens-morgenstern/async/issues/70 https://github.com/klemens-morgenstern/async/issues/64 Finally, while the above might look like a list of complaints, I really appreciate the work that was done in order to provide this library, and the solutions that were applied (like the clever use of await_transform). I learned a lot from studying this library, and my intuition tells me that it will end up being a great addition to Boost. I also appreciate the responsiveness of the author. Klemens has been answering a lot of my questions in a timely fashion, and improving the docs based on feedback. Thanks! Regards, &rzej;

2 2

[Async] Second attempt at review of proposed Boost.Async begins
by Niall Douglas 01 Oct '23

01 Oct '23

Dear Boost, Due to too few reviews last time, we are going to try again the review of this library. This review shall run between Friday 22nd September and Monday 2nd October. Please do consider contributing a review! My thanks to Marcelo Zimbres Silva for the only formal review last time, and to the others including those on Reddit /r/cpp and by private email who submitted feedback. All your reviews and feedback have been retained and will be reused for this review. To remind you all, Boost.Async is a C++ coroutine programming library based around Boost.ASIO as the executor, with a unique set of properties which make it incomparable to most existing C++ coroutine programming libraries. To be specific, it lets you compose arbitrary third party awaitables without any additional effort, which lets you tie together third party libraries with ease and convenience. Changes to proposed Boost.Async since the last review: 1. Major doc improvements & bug fixes 2. PMR is optional 3. optimized associated allocator for use_op 4. lazy generator support 5. public unique_handle & more examples with custom awaitables 6. as_result/as_tuple support (akin to the asio stuff, but takes an awaitables, i.e. co_await as_result(foo())) - reduces unnecessary exceptions. 7. with supports return values. You can read the documentation at https://klemens.dev/async/ and study or try out the code at https://github.com/klemens-morgenstern/async. Anyone with experience using C++ coroutines is welcome to contribute a review at the Boost mailing list (https://lists.boost.org/mailman/listinfo.cgi/boost) at /r/cpp on Reddit, via email to me personally, or any other mechanism where I the review manager will see it. In your review please state at the end whether you recommend acceptance, acceptance with conditions, or rejection. Please state your experience with C++ coroutines and ASIO in your review, and how many hours you spent on the review. Thanks in advance for your time and reviews! Niall

4 4

[Async] Reminder that peer review ends on Monday
by Niall Douglas 29 Sep '23

29 Sep '23

A reminder to Boost folk that the proposed Boost.Async review ends on Monday 2nd October. I have received no new reviews since this second review began. You can read the documentation at https://klemens.dev/async/ and study or try out the code at https://github.com/klemens-morgenstern/async. Niall

2 1

Re: [boost] Fwd: [boost.async] Andrzej's review
by Niall Douglas 29 Sep '23

29 Sep '23

Andrzej, Firstly, it's weird I don't see this on the Boost mailing list. In fact, I seem to only get about half the mail to the Boost mailing list ever since they fiddled with the servers. So thanks for sending this review to me directly. I've also caught up with all your other posts on Boost.Async from https://lists.boost.org/Archives/boost/2023/09/index.php, none of which I had seen before now. Thanks for the review. If you don't mind if I jump in with a few bits myself which are intentionally not about the review itself ... On 29/09/2023 14:08, Andrzej Krzemienski wrote: > Regarding the choice and design of "coroutine types", I have certain > reservations. > It is still not clear to me why we have two -- promise and task -- and > when I should use which. The docs give some answer: promise is > eager, task can be awaited/spawned on another executor than it was > created on. But is that it? I sense that there is a good reason to have > them as two types, a better/clearer one than this described in the > docs.But I fail to see it, and the docs do not explain it clearly > enough, I think. Outcome calls the same thing eager and lazy. I felt lazy is a more descriptive name than task. I mean, why should a task be lazy rather than eager? The reason is simply because Lewis Baker happened to choose that default, and it's stuck since, but there isn't any strong rational for "task ~= lazy" other than convention. > One problem is how the `generator` signals that it has finished. In all > the examples it has to create a dummy value. I hear from Klemens that it > is a necessity imposed by the coroutine design in C++. I do not feel > competent to confirm it or not. But I note that std::generator does not > require the user to `co_return` anything. And that > asio::experimental::coro does allow the user to specify that they do not > want to co_return even if they co_yield things. It's been a while since I used coroutine generators, but my memory is when the coroutine exits then the generator returns its end iterator value. I don't remember dummy values. But then I 99.9% use C++ coroutines with Result, to avoid ever throwing C++ exceptions through C++ coroutine machinery which *still* is riddled with showstopper bugs in current compilers. > On the documentation. The only other library offering coroutine support > and any documentation that I know of is Boost.ASIO. There are actually a good few Boost libraries with C++ coroutine support now in one form or other. Outcome is obviously one, but there is at least one other apart from ASIO (somebody else may remind me which one now). Boost.Async's are much fuller featured obviously, but even Outcome's simple ones are usually good enough for most use cases. You don't need to use them with Result either. > But this doesn't work, because now I am co_yield-ing from a > non-coroutine. And I have to resort to manually inspecting the variant, > which is taught to be error prone. BTW tip for the future: just use helper coroutine lambdas if you need to do coroutine stuff from within normal code. These normally don't work with the Coroutine support from cppcoro, stdexec, libunifex nor ASIOs because their coroutines don't allow it. But Boost.Async's does, as does Boost.Outcome's. It cannot be understated the usefulness of being able to dip in and out of "coroutine land" using inline lambdas from normal code. It makes C++ coroutines vastly more convenient to use. Niall

2 1

[fiber] Moving fibers between threads
by Niall Douglas 28 Sep '23

28 Sep '23

Dear Boost, At work I need to move a Boost Fiber from one kernel thread to another. There is a dedicated documentation page for this: https://www.boost.org/doc/libs/1_83_0/libs/fiber/doc/html/fiber/migration.h… What that page doesn't say is how to migrate yourself if you're currently within a Fiber to another kernel thread, as the docs only talk about migrating Fibers currently not executing and in the ready not sleeping state. I guess this would work: 1. Create a new Fiber, and go into a loop giving up the current execution. 2. When that new Fiber executes, migrate the original fiber to its new kernel thread, then have it exit the loop so it proceeds. Then self immolate, as you're done. But now you're creating and destroying a whole Fiber just to migrate a Fiber between kernel threads, and that feels icky. I don't suppose there's a better way e.g. some sort of way of asking the current thread's Fiber scheduler to call a function when it's next not executing a Fiber? That would avoid the needless Fiber creation and destruction per migration of a Fiber across kernel threads. Thanks for help in advance. Niall

3 3

[boost.async] Dummy co_return from a generator
by Andrzej Krzemienski 24 Sep '23

24 Sep '23

Hi Everyone. I am very uneasy about the dummy co_retuned value that I see in the examples of async::generator. Like the one in the echo server example: https://klemens.dev/async/tutorial.html#echo_server async::generator<tcp_socket> listen() { tcp_acceptor acceptor({co_await async::this_coro::executor}, {tcp::v4(), 55555}); for (;;) { tcp_socket sock = co_await acceptor.async_accept(); co_yield std::move(sock); } co_return tcp_socket{acceptor.get_executor()}; // :-( } The control will never get to the co_return. The caller never even tries to observe this value. and yet we are forced to return it. Interestingly, the coroutine example from ASIO doesn't have this due to a different design: https://www.boost.org/doc/libs/1_83_0/doc/html/boost_asio/example/cpp20/cor… std::generator doesn't have this. In other examples the degenerate value is used to indicate the end of generation. I do not know the coroutines to be able to tell if this is a design problem with async::generator or with C++ coroutines in general. But it feels wrong that the end of generation should be signaled in this way. Regards, &rzej;

2 5

[boost.async] a note on documentation
by Andrzej Krzemienski 23 Sep '23

23 Sep '23

Hi Everyone, In the context of the Boost review of Boost.Async, I wanted to share a thought on documentation. I think the Reference section in the docs is insufficient. A lot of libraries in Boost have this approach that the reference section of the documentation is a specification exhaustive enough that it could be used to provide a number of competing implementations. Each function has a very detailed contract: what it returns and when, what are the preconditions, what exceptions are thrown upon failure, what are the postconditions. I am missing this from the reference of Boost.Async. Also, it may be one of the first libraries (that meet a certain bar of documentation) tied so much to coroutines, so I have no strict requirements on how a coroutine library is documented, but I think things like promise types should be explicitly referenced. Let's consider `async::generator`. It is not only class template `generator`, but also: 1. the specialization of type trait std::coroutine_traits 2. Class template `generator_promise` 3. generator_promise 4. generator_receiver 5. awaitable types Even though some of them belong to namespace `detail`, they provide guarantees relevant for the users. I do not think `generator_promise`is an implementation detail. I think it needs to be documented. This seems especially important when I start adding my awaitables to the mix. I wonder what others think about it? Regards, &rzej;

2 5

Seeking Endorsement for Charconv
by Matt Borland 22 Sep '23

22 Sep '23

Hello, At the beginning of the summer I solicited feedback for an in-progress C++11 implementation of <charconv> for a proposal to Boost. The library is now complete with that feedback incorporated, and I am seeking endorsement. Should the library receive endorsement Chris Kormanyos has volunteered to serve as the review manager. What is Charconv? It is a character conversion library that converts a character sequence into a number (from_chars) or converts a number into a character sequence (to_chars). This is similar to strtod and printf with two key differences. First and most important is a roundtrip guarantee. That is a number converted into a character sequence, and then back into a number will be identical to the starting value. Second, you can easily specify an input/output format with a chars_format argument, and also provide a target precision. Lastly, instead of requiring recent compilers (e.g. GCC 11, and MSVC 19.24) and C++17 to get full support for <charconv> you can have it now with GCC 5, Clang 3.7, or MSVC 19.00 and C++11. What types are supported? All builtin integers plus __int128 and unsigned __int128. For floating point types all built-in IEEE 754 compliant types to include those provided in C++23’s <stdfloat>, and __float128. A notable example of a non-IEEE 754 compliant built-in type is ibm128 provided on older versions of PowerPC. How do I use the library? The repo can be found here: https://github.com/cppalliance/charconv. Since this is a compiled library, directions for use with b2, vcpkg, and conan are provided. What is the performance like? I added a table of benchmarks (https://master.charconv.cpp.al/#ref_benchmarks) that compares this implementation to the performance of: STL (printf, strtoX, and <charconv>), Boost.Lexical_Cast, Boost.Spirit, and libdouble-conversion. In summary we meet or exceed the performance of GCC and MSVC <charconv>, and exceed by up to several multiples the performance of all the other libraries. Thanks to Stephan T. Lavavej for providing his benchmarking file in the original discussion. Why is this not going into Boost.Compat? The size of this library exceeds the scope of Boost.Compat. Compat is designed for headers that can be implemented in a small amount of code. <latch> with implementation, testing and documentation was ~350 LOC while Charconv is ~29,500. Please let me know if you have any questions or issues with the library. Thanks, Matt Borland —- C++ Alliance Staff Engineer

5 7

Async review scheduled for September 22, 2023 - October 2, 2023
by Mateusz Loskot 08 Sep '23

08 Sep '23

Hi, Following request from Nial and Klemens, we have scheduled new round of the Async review for September 22, 2023 - October 2, 2023 https://www.boost.org/community/review_schedule.html Best regards, -- Mateusz Loskot, on behalf of the Review Wizards

3 2

Presenting BoostServerTech chat
by Ruben Perez 07 Sep '23

07 Sep '23

Hi all, I'm Ruben, the author of Boost.MySQL, and I want to present (and maybe get some feedback about) a project I'm developing to showcase how to do async stuff with Boost server-side. This started because I want to write a connection_pool class for MySQL. It's a complex feature with a lot of trade-offs, and I wish I had more field experience to guide me when making the required decisions. We currently have great libs for async networking (Asio, Beast, Redis, MySQL). They've got examples and docs, but I think they sometimes fall short. Often users get lost since setting up an async server is not trivial, and we offer a lot of flexibility that can sometimes stun newcomers. So I've decided to blend these two needs together and create a project that allows Boost authors to try new things in a realistic environment, while demonstrating to users how they can use Boost to build an app. (Note: this is **not** a Boost library, and will never be). Code: https://github.com/anarthal/servertech-chat/ Docs: https://anarthal.github.io/servertech-chat/ Live demo: http://13.48.215.34/ It's still a work-in-progress. Although I've implemented some features, I've tried to focus on the skeleton, getting testing, deployments and C++ best practices in place. I plan on adding more stuff in the future, like showing how you can call 3rd party REST APIs using Boost. One cool feature is that, if you have an AWS account, you can fork the repo and get a live server in minutes (see https://anarthal.github.io/servertech-chat/03-fork-modify-deploy.html) I actually envision this as a series of projects, showcasing different applications and needs. I originally wrote this document (https://docs.google.com/document/d/1ZQrod1crs8EaNLLqSYIRMacwR3Rv0hC5l-gfL-j…) describing how I saw it. If any other author wants to step forward and create their own ServerTech application, please let me know. I'd like to have some (hopefully constructive) feedback from you guys. I'd thank you if you give the live demo a try. And if someone's interested, there's a ton of work to do, so let me know. Note: if you've scanned through the code and you're asking "where is the connection_pool" - nowhere yet, that's still to come. Thanks, Ruben.

5 8

Boost Solvers Library
by Pascal Kesseli 03 Sep '23

03 Sep '23

In the course of my research in static program analysis, I have been a contributor to the Bounded Model Checker for C (CBMC - https://github.com/diffblue/cbmc) for quite some time now. Projects like these map static analysis problems to a variety of back-end solvers like SAT, SMT, QBF, etc. What always surprised me is how often tools like CBMC have to come up with an intermediate C++ layer for the various back-end solvers like MiniSAT or Glucose (see https://github.com/diffblue/cbmc/tree/develop/src/solvers/sat) For this reason I am considering to create a unified C++ wrapper for these different solvers, with an initial focus on SAT. I intend to include a naive default DPLL implementation, but the real value for such a library would stem from making the aforementioned third party engines easily accessible. I was wondering whether this would be a fit for a Boost library, but I am uncertain whether: A) There is even interest in the community for this or B) The scope of the library with inherent dependencies on external SAT solvers fits the Boost format Thus I thought I'd drop this message in the mailing list to ask what people think. Thanks,

1 0

[boost.async] Some feedback
by Andrzej Krzemienski 29 Aug '23

29 Aug '23

Hi Everyone, I will not be able to write a decent review due to the lack of time (I am now on vacation), but I wanted to share some partial feedback. I am not well familiar with C++ coroutines. I wrote some toy examples of an async TCP echo server in ASIO in the past, to try to learn how coroutines work, but my knowledge is very superficial. I hoped to understand coroutines better from studying Boost.Async's docs. When I discovered Boost some 18 years ago, I found it useful not only because of the high quality libraries but also because of extraordinary documentation that often provided a very deep insight into the problem domain, a lot of rationale, design goals, and the documentation of engineering trade-offs of different sorts. I do not know how people feel about the importance of documentation nowadays. For me, however, it is the primary focus. I devoted like 10 hours in total for studying the docs and running some toy examples. Because I am not very good at C++ coroutines, you get a typical, I would think, feedback from a user that wants to learn how coroutines are used, what problems they solve, and what problems they do not solve. Regarding the *really* asynchronous part, promises and tasks, I guess they would work fine. By "really asynchronous" I mean the situations where a coroutine is resumed by events unpredictable by the programmer (when data arrives, when certain time passes, when an external connection is requested). I also guess that when Marcelo and Ruben say they successfully integrated Boost.Async into their projects, they meant types `task` and `promise`, rather than `generator`. My investigation was interrupted by `generator` which I cannot understand or appreciate. It feels like a type quite separate from the rest of the library. For instance, through all the simple examples in the docs, only the examples for `generator` never use the trick with `co_await async::this_coro::executor`. I needed to ask a lot of questions, and even though Klemens is very responsive and very helpful, I still do not understand how `async::generator` solves real problems. This may indicate that either I am a very slow learner, or that there is something wrong with the design of `generator`. But even if it is the former, I think I represent the average user of this library. When I try to use a C+23 std::generator, the usage is intuitive and straightforward to me. I know how to easily yield a sequence of values, and on the caller side how to easily check if I can still obtain the next value from the generator: ``` std::generator<int> seq(int from, int to) { for (int i = from; i <= to; ++i) co_yield i; } int main() { for(int i : seq(1, 4)) std::cout << i << std::endl; } ``` https://godbolt.org/z/PTvz3v4Y6 But when I try what I believe to be an analogous example in Boost.Async, I get an exception: ``` async::generator<int> seq(int from, int to) { for (int i = from; i <= to; ++i) co_yield i; } async::main co_main(int argc, char* argv[]) { auto s = seq(1, 4); while (s) { std::cout << co_await s << std::endl; } } ``` And the docs or examples don't help me understand why this use case doesn't work. The case with the eager generator that can be injected values is even weirder. I think it is wrong. Klemens thinks otherwise, but the docs do not give any convincing example of where and how it could be used. The lack of examples or description can be just that, but it could also indicate that the design for generators is missing something. In this feedback, I am only mentioning generators, because this is the place where I stuck in my review. I guess that other parts of the library do not have this problem. I am pretty sure that this library will be accepted into Boost at some point. It addresses a real need (although not necessarily the generators), and the feedback from Ruben and Marcelo are strong testimony to the quality of the library. But at this point, I am not comfortable with adding a library whose design for generators cannot be explained in the docs to the extent that I consider satisfactory. Would this library lose in usability if generators were removed? I know it is not a fair review. I only covered one subject, and my feeling is that it is not the most relevant one. So please consider it as "just feedback" rather than a review. Again, thanks Klemens for writing and sharing this library. I hope that this message does not come across as negative. I want to think that I am contributing to the quality of Boost.Async. Regards, &rzej;

2 2

remez, chebyshev polynomial approximation
by Brian Budge 25 Aug '23

25 Aug '23

Hi folks - I have a couple of questions regarding the math tools for polynomial approximation. Context: I'm interested in making fast math approximations that are also highly accurate. These include standard functions, but also custom fits. I've successfully used the chebyshev_transform and remez tools to make such approximations. However, I know in many cases I could get better results. So my questions are the following: 1. For the remez tool, how could we constrain e.g. odd or even powers of numerator, denominator, or both to zero? This is common in highly accurate trig approximations for example. Looking at the code, I suspect we'd need to change the degrees of freedom for the solver, but I don't know how straightforward it would be to make such a change (or if there are theoretical reasons why this couldn't work with the remez algorithm) 2. Getting accurate results with chebyshev_transform requires the Crenshaw algorithm, which makes these approximations far slower than those I get from the remez tool. Are there a class of polynomials where I could transform these to a standard Horner's or Estrin's scheme in a way that is numerically stable? If so, any pointers to how to do that? Thanks, Brian

2 3

[Async] Try again review
by Niall Douglas 23 Aug '23

23 Aug '23

I received one formal review, and two bits of substantial feedback. My thanks to their authors. I received more formal requests to run the review in September than reviews, so I guess we're going to have to try this review again. Does anybody object to Friday 15th September to Monday 25th of September? Niall

5 11

[boost.async] Some questions
by Andrzej Krzemienski 20 Aug '23

20 Aug '23

Hi Everyone, I would like to thank Klemens for writing and sharing this library. I am sure the community needs a higher level library for asynchronous computations based on C++20 coroutines. Boost.Async addresses the need. I would like to ask a couple of questions to better understand the design goals and the scope of the library. Q1. Is single-threaded-ness the design goal? Or is the plan to enable multi-threaded use cases? There is a GitHub issue ( https://github.com/klemens-morgenstern/async/issues/19) suggesting the latter. Q2. Reading through the docs, I get an impression that Boost.Async is "Either a wrapper over ASIO, or an isolated usage for a generator". They seem like two unrelated worlds. The former requires a hard prerequisite of having a Boost.ASIO library (with Boost version at least 1.82). The latter can hardly be called "asynchronous". Generators, the way I understand them, are perfectly synchronous. Is this impression correct? The following are more remarks regarding the choice of names. Q3. The docs say that `promise` and `task` differ primarily by their level of eagerness. But the names do not seem to reflect this. What is the rationale or the intuition behind those names? R1. I find the name `use_op` uninformative. The examples in documentation suggest that it is an *adapter*: they change the Boost.ASIO interface into the Boost.Async interface. Is that correct? Regards, &rzej;

3 11

[boost.asynch] another generator query
by Andrzej Krzemienski 19 Aug '23

19 Aug '23

Hi Klemens, I have another question regarding the generator. I think the initial examples in the dcs for `generator` are too simplistic, because the caller seems to already know how many times it is allowed to co_await on the Awaitable. I tried it with a loop, where I use the explicit conversion to bool to check when to break the iteration: ``` async::generator<std::string> worker(int limit) { for (int i = 0; i < limit; ++i) { co_yield std::format("--{}--", i); } } async::main co_main(int argc, char* argv[]) { try { auto w = worker(3); while (w) { std::cout << co_await w << std::endl; } } catch (std::exception const& e) { std::cout << "ERR: " << e.what() << std::endl; } } ``` But I am surprised that this construct ends with throwing an exception. Am I doing something wrong? Regards, &rzej;

2 2

[Async] Review of proposed Boost.Async begins
by Niall Douglas 18 Aug '23

18 Aug '23

Dear Boost, It is my great pleasure to announce the beginning of the peer review of proposed Boost.Async, which is hoped to become the most popular way of programming C++ coroutines in future C++. The peer review shall run between Tuesday 8th August and Friday 18th August. Like many of you have found, until now there has been no good standard and easy way of writing C++ coroutine code which works easily with multiple third party codebases and foreign asynchronous design patterns. ASIO’s current coroutine support is tightly coupled to ASIO, and it rejects foreign awaitables. Libunifex is dense to master and non-obvious to make work well with foreign asynchronous design patterns, not helped by a lack of documentation, a problem which also afflicts stdexec which also has a steep and dense learning curve. CppCoro is probably currently the best in class solution to the space of easy to use fire and forget C++ coroutine programming, but it isn’t particularly portable and was designed long before C++ coroutine standardisation was completed. Klemens very kindly stepped up and created for us an open source ground-up reimplementation of the best ideas of hitherto proprietary commercial C++ coroutine libraries, taking in experience and feedback from multiple domain experts in the area to create an easy to use C++ coroutine support library with excellent support for foreign asynchronous design patterns. For example, if you want your coroutine to suspend while a stackful fiber runs and then resume when that fiber has done something – AND that fiber implementation is unknown to Boost.Async – this is made as easy as possible. If your C++ coroutine code wants to await on unknown foreign awaitables, that generally “just works” with no added effort. This makes tying together multiple third party dependencies into a solution based on C++ coroutines much easier than until now. The industry standard executor is ASIO, so Boost.Async uses Boost.ASIO as its base executor. To keep things simple and high performance, Boost.Async requires each pool of things it works with to execute on a single kernel thread at a time – though there can be a pool of things per kernel thread, or an ASIO strand can ensure execution never occurs on multiple kernel threads. The basic concurrency primitives of promise, generator and task are provided, with the fundamental operations of select, join and gather. Some more complex async support is supplied: Go-type channels, and async teardown. Performance is superior to both stackful coroutines and ASIO’s own C++ coroutine support, and sometimes far superior. You can read the documentation at https://klemens.dev/async/ and study or try out the code at https://github.com/klemens-morgenstern/async. Anyone with experience using C++ coroutines is welcome to contribute a review at the Boost mailing list (https://lists.boost.org/mailman/listinfo.cgi/boost) here at this Reddit page, via email to me personally, or any other mechanism where I the review manager will see it. In your review please state at the end whether you recommend acceptance, acceptance with conditions, or rejection. Please state your experience with C++ coroutines and ASIO in your review, and how many hours you spent on the review. Thanks in advance for your time and reviews! Niall

8 13

[Async] Review ends tomorrow
by Niall Douglas 17 Aug '23

17 Aug '23

Dear Boost, The peer review of Boost.Async ends tomorrow. Currently no reviews have been received, there has been almost no discussion, and it appears nobody has been testing Klemens' library. Unless there is a major change by tomorrow, I suspect we'll have to try this again next month when more people return from summer holidays. Niall

4 3

Review of proposed Boost.Async
by Ruben Perez 15 Aug '23

15 Aug '23

Hi all, Thanks Klemens for submitting this library. I've taken a different approach for the review this time. I've tried to build something useful with it. I was already writing a web chat application with a C++ backend. It was using Boost.Context coroutines (the ones you get with boost::asio::spawn). I have rewritten the server to use Boost.Async coroutines. This email is not a review (I'll write it later), but just a summary of my experience using the library, in case anyone finds it useful. You can see the full source code here: https://github.com/anarthal/servertech-chat/tree/async-rewrite/server The application =============== It is a super-simplistic chatting application, where users can send messages that get broadcast to other users in the same chat room. The application uses a HTTP webserver to serve static files, websockets for message broadcasting and Redis for message persistence. It uses Boost.Asio, Boost.Beast, Boost.Redis and now Boost.Async (together with other foundational Boost libraries). My experience ============= I've been able to rewrite it and make it work. I've had some problems (which I described below) but have been able to solve them. Control flow was mostly identical to stackful coroutines, except in some key places I describe below. I've used the use_op token extensively to interoperate with Beast and Redis. As proposed, it causes problems with Beast's websockets, as it's moving the websocket's internal implementation. As a result, after the first initiation that uses use_op, the websocket is rendered unusable. I could overcome it by slightly modifying use_op's implementation. This is tracked by https://github.com/klemens-morgenstern/async/issues/68. It's still under discussion whether this is a bug in Async or in Beast. use_op uses a per-operation, stack-based memory pool of 2KB internally. It creates a completion handler with an associated allocator that will consume this stack-based memory before calling operator new. The pool gets destroyed once the co_await expression finishes execution. I had a problem with Boost.Redis, where redis::connection::async_exec was calling complete() without releasing the memory allocated in the operation, which led to crashes. I think it's a problem in Boost.Redis, not in Async. Tracked by https://github.com/boostorg/redis/issues/140. By default, use_op converts error codes to exceptions. This is consistent with Asio's use_awaitable, but it's a setting I personally don't like using. However, it's easy to adapt it by using asio::as_tuple(async::use_op) as completion token. This should probably be mentioned in docs. I'm using async::with to clean-up Redis connections on application exit. I think it's a very useful feature, and one that Asio doesn't offer. It would be a nice addition to be able to return values from the with call though, to make code less verbose. Tracked by https://github.com/klemens-morgenstern/async/issues/69. As any Beast-based HTTP server, my code has a TCP acceptor that listens for connections and launches HTTP sessions. At first, I was running these sessions as detached promises (by using async::promise::operator+). This caused a deadlock on finalization. async::co_main does not cancel detached promises, but does wait for them to finish after receiving a SIGINT. I solved this by placing my promises in an async::wait_group instead of detaching them. However, I think this behavior is non-obvious and can cause problems for people less experienced with Asio. I've raised https://github.com/klemens-morgenstern/async/issues/72 to track this. I'm currently using detached promises to broadcast messages over websocket sessions. Compared to asio::spawn, spawning detached tasks in Boost.Async is significantly easier. As you may know, when using Beast's websockets, you need to make sure that the application doesn't perform two concurrent async reads or writes on the same websocket at the same time. In this chat server, two concurrent writes can happen if two messages need to be broadcast at the same time. Thus, I was using a hand-rolled async_mutex, based on Asio channels, to guarantee mutual exclusion (unfortunately, there is no asio::mutex). I tried re-writing my async_mutex using async::channel, but I couldn't, because my implementation relied on asio::channel::try_send, which Async does not offer. It would be great if this library could offer async locking primitives, like mutex, condition_variable or event, like Python's asyncio does. I don't think this is a requirement for inclusion, though. I then decided to remove the mutex and base my strategy on channels. Websocket reads and writes are now managed by a single coroutine. If any other session needs to write through a different session's websocket, it writes a message through a channel. The coroutine running the websocket session reads from the websocket and the channel in parallel, using async::select. My first, naive implementation used async::select(websocket.async_read(..., use_op), channel.read()). This does not work as intended because, if the channel read completes first, select will cancel the websocket read, which will cause the websocket connection to close. This can be overcome easily with generators, as they implement the wait_interrupt mechanism. If the channel read completes first, the generator can be resumed later, without losing information. Although there exists an asio::experimental::parallel_group with similar functionality, I don't think this channel-based strategy could be achieved using plain Asio, since the non-destructive capabilities of the generator are vital. parallel_group is also almost undocumented, which makes it difficult to use. My only concern with channels as they are is that channel.read() will throw an exception on cancellation. This means that async::select(websocket_generator, channel.read()) will throw-and-catch an exception internally every time a message arrives on the websocket. I believe that exceptions should be exceptional, and it's not the case here. It makes debugging harder, and may have a performance impact (which I haven't measured). https://github.com/klemens-morgenstern/async/issues/76 tracks this. I've been able to successfully build this project using clang-17 under Linux. I had problems building wait_group under gcc-12 (https://github.com/klemens-morgenstern/async/issues/73) Some other minor issues I found: * https://github.com/klemens-morgenstern/async/issues/75 * https://github.com/klemens-morgenstern/async/issues/66 * https://github.com/klemens-morgenstern/async/issues/71 Some of these issues have already been fixed in the develop branch by Klemens. If you're trying the library, I'd advise you to use this branch. Questions ========= Q1. Is it possible to somehow address the deadlock problem? Q2. Is it possible to get non-throwing overloads of the channel functions? Q3. The docs mention that MSVC compilers have broken coroutine implementations. What compilers/OS does this library target/has been tested with? Thanks Klemens for making the async world less painful. Regards, Ruben.

1 0

Review of proposed Boost.Async
by Marcelo Zimbres Silva 14 Aug '23

14 Aug '23

Hi, this is my review of the proposed Boost.Async. Before I issue my final decision (ACCEPT/REJECT) I would like to ask the author some questions. First of all, I have plenty of reasons to want a library such as Boost.Async into Boost. Some of them are * A common concern I hear from my peers is that Asio is too difficult to get started with. One of the reasons for that is that its Universal Asynchronous Model built around the completion token is too generic for most use cases and in some cases encourages just bad practice like the use_future token. A library like Boost.Async that adds a thin coroutine-only layer over Asio and its corresponding facilities like select, gather etc. will lower the entrance barrier in the Asio asynchronous world. * Docs: Even Asio experts agree that Asio documentation is not easily digestible (async_initiate I am looking at you) and I think it will be difficult for its author alone to address users' complaints given how low-level and generic Asio is. Also, regular users should not be bothered with many of the details. Boost.Async documentation is linear and to the point. It uses names that are more easily recognized by people coming from other languages, like select and with. * NodeJs and Go Tokio, etc. have shown us that successful networking libraries will flourish once a decent asynchronous environment is available. We have more than that, Asio is robust and battle tested, but I am afraid it might not be the correct ground on which high-level abstractions should be prototyped and evolved, not every library needs Duff's device to perform some milliseconds better. As I mentioned above, it is perhaps too generic and low-level and a layer over it might be necessary. Boost.Async looks like the correct step in that direction. We will be one step closer to writing code that is as simple as python, NodeJs, etc. but that runs at C++ speed. * It will help us gather more field experience with C++20 coroutines in domains where C++ is extensively used, like high-performance network servers. * Boost.Async has good defaults, for example a single threaded context. Too many people play around with multi-thread io_context and strands not knowing it might actually have a negative impact on performance. This is also likely to play well with other network Boost networking libraries like Boost.Beast, Boost.MySql and Boost.Redis. Also, the automatic installation of signal handling is a good thing. Q1: Default completion token for other Boost libraries ================================================================ I guess it will be a very common thing for all apps using Boost.Async to have to change the default completion token to use_op or use_task. Like you do in the examples > using tcp_acceptor = async::use_op_t::as_default_on_t<tcp::acceptor>; > using tcp_socket = async::use_op_t::as_default_on_t<tcp::socket>; Could this be provided automatically, at least for other Boost libraries? I know this would be a lot of work, but it would make user code less verbose and users would not have to face the token concept at first. Q2: Lazy vs Eager ================================================================ > It’s an eager coroutine and recommended as the default; Great, we can experiment with eagerness and laziness. But why is an eager coroutine recommended as default? Q3: async_ready looks great ================================================================ > We can however implement our own ops, that can also utilize the > async_ready optimization. To leverage this coroutine feature, async > provides an easy way to create a skipable operation: I think I have a use case for this feature: My first implementation of the RESP3 parser for Boost.Redis was based on Asio's async_read_until, which like every Asio async function, calls completion as if by post. The cost of this design is however high in situations where the next \r\n delimiter is already in the buffer when async_read_until is called again. The resulting rescheduling with post is actually unnecessary and greatly impacts performance, being able to skip the post has performance benefits. But what does *an easy way to create a skipable operation* actually mean? Does it - avoid a suspension point? - avoid a post? - act like a regular function call? Q4: Synchronization primitives ================================================================ Will this library ever add synchronization primitives like async mutexes, condition variables, barriers etc. Or are they supposed to be used from an external library like proposed Boost.Sem. Q5: Boost.Async vs Boost.Asio ================================================================ I use C++20 coroutines whenever I can but know very little about their implementation. They just seem to work in Asio and look very flexible with use_awaitable, deferred, use_promise and use_coro. What advantage will Boost.Async bring over using plain Asio in regards to coroutine? NOTE1 ================================================================ > Please state your experience with C++ coroutines and ASIO in your > review, and how many hours you spent on the review. I have spent a bit more than a day reading the docs, writing the review and integrating Boost.Redis. My experience with C++20 coroutines is limited to using them with Asio. I would also like to thank Klemens for submitting Boost.Async and Niall for offering to be its review manager. Marcelo

3 4

Re: [boost] [Async] Review of proposed Boost.Async begins
by Niall Douglas 14 Aug '23

14 Aug '23

On 08/08/2023 06:33, Niall Douglas wrote: > It is my great pleasure to announce the beginning of the peer review of > proposed Boost.Async, which is hoped to become the most popular way of > programming C++ coroutines in future C++. The peer review shall run > between Tuesday 8th August and Friday 18th August. A reminder that five days remains for this review. To date, I have received zero reviews. Niall

3 2

The master branch is now open for all changes
by Marshall Clow 11 Aug '23

11 Aug '23

Next deadline: October 25th - Boost 1.84.0 closed for new libraries and breaking changes` As always, the calendar is at: https://www.boost.org/development/ — Marshall

1 0

[release] Boost 1.83.0
by Marshall Clow 11 Aug '23

11 Aug '23

Release 1.83.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 one new library: * Boost.Compat: A repository of C++11 implementations of standard components added in later C++ standards, from Peter Dimov and contributors. The release also contains numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.83.0> You can also download directly from: <https://boostorg.jfrog.io/artifactory/main/release/1.83.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. -- The Boost Release Team Marshall Clow, Glen Fernandes

1 0

[release] Boost 1.83.0 Release Candidate 2 is available
by Marshall Clow 10 Aug '23

10 Aug '23

The second release candidates for the 1.83.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.83.0/source/> The SHA256 checksums are as follows: c86bd9d9eef795b4b0d3802279419fde5221922805b073b9bd822edecb1ca28e boost_1_83_0_rc2.zip 6478edfe2f3305127cffe8caf73ea0176c53769f4bf1585be237eb30798c3b8e boost_1_83_0_rc2.tar.bz2 c0685b68dd44cc46574cce86c4e17c0f611b15e195be9848dfd0769a0a207628 boost_1_83_0_rc2.tar.gz 22ee9dcf3f1fb58f585772f70c69113a4077b92adeac58b643b3543b78633a16 boost_1_83_0_rc2.7z The only change between RC1 and RC2 is the addition of some missing "#include"s in Boost.Unordered 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 Release managers

5 5

[release] Boost 1.83.0 Release Candidate 1 is available
by Marshall Clow 08 Aug '23

08 Aug '23

The first release candidates for the 1.83.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.83.0/source/> The SHA256 checksums are as follows: 9e99f679ea059a25a11bbcb46141868b71c1b33cf89fac916fa392cff20d1577 boost_1_83_0_rc1.7z 4c1cfd15a92ce003a5c2f4bd11311225e7fe42c6686bffabc64e41534167395d boost_1_83_0_rc1.tar.bz2 0571eb39fc0dd92cc8d1d01d3197c58bb28043392e1038df57090676fd6574fa boost_1_83_0_rc1.zip 2d6cf669fb45a2c1e2f92f90c9d444b19a4af25420fbf54747366f637a22a3f7 boost_1_83_0_rc1.tar.gz 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 Release managers

8 13

Status of the 1.83.0 release
by Marshall Clow 08 Aug '23

08 Aug '23

On Thursday, we created 1.83.0 RC1. There have been two problems reported against it. * A couple of missing “include” statements in Unordered * A regression against 1.82.0 (code that used to compile no longer does) in Stl_interfaces. https://github.com/boostorg/stl_interfaces/issues/62 Zach has opined to me that this failure in stl_interfaces is deliberate; so we will not be addressing that. We will be producing an RC2 later today/early tomorrow with the fix for Unordered. This means that the release will probably NOT happen on Wednesday, 9-Aug. Hopefully Thursday. — The release managers.

1 0

[release] Master Branch is closed for ALL changes
by Marshall Clow 03 Aug '23

03 Aug '23

Please do not commit anything to the master branch. Other branches are always fine. The 1.82.0 release is scheduled for next Wednesday, 10-Aug. — Marshall

1 0

Master Branch is now open for bug fixes
by Marshall Clow 02 Aug '23

02 Aug '23

The master branch is now open for bug fixes and documentation changes. Other changes by release manager permission, as described in https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy The next deadline: On August 5th, master closes for all changes. As always, the calendar is at https://www.boost.org/development/ — Marshall

4 7

oneAPI build
by Alain O' Miniussi 01 Aug '23

01 Aug '23

Hi, I'm trying to build master with oneAPI 2023.1.0's icpx. So far I am mostly getting warnings for unknown/unsupported options like: icpx: warning: -Wl,-rpath,/data/spack/opt/spack/linux-centos7-x86_64/gcc-12.2.0/intel-oneapi-mkl-2023.1.0-x6dxpakvvn4sntkmbzqvtjdndc3g5ttn/mkl/2023.1.0/lib/intel64: 'linker' input unused [-Wunused-command-line-argument] intel-linux.compile.c++ bin.v2/libs/log/build/intel-linux-2023.1.0/release/cxxstd-17-iso/threading-multi/visibility-hidden/setup/matches_relation_factory.o icpx: command line warning #10430: Unsupported command line options encountered These options as listed are not supported. For more information, use '-qnextgen-diag'. option list: -ip -wd177,780,2196,1782,193,304,981,1418,411,734,279 Is oneAPI supported ? the following page: https://www.intel.com/content/www/us/en/developer/articles/technical/buildi… only mention 1.75 and 1.78 Thanks Alain

2 2

Request to merge fixes to docca
by Krystian Stasiowski 28 Jul '23

28 Jul '23

I would like to merge the following commits: https://github.com/boostorg/docca/commit/0ce4e198398dbb52f1de0029f4ed9b7d2b… https://github.com/boostorg/docca/commit/8ba36c0c1e1adb32dbf4cd9c7f3cb36f33… https://github.com/boostorg/docca/commit/4b61682742d6fc0d373698d42635024088… To address these issues: https://github.com/boostorg/docca/issues/136 https://github.com/boostorg/docca/issues/105 These fix assorted compatibility issues with doxygen 1.8.16 and newer

2 1

[boost.async] Seeking Endorsement
by Klemens Morgenstern 28 Jul '23

28 Jul '23

Dear fellow Boost developers, I am seeking endorsement for my C++20 async coroutine library boost.async. It provides coroutine primitives & utilities that are easy to use and intuitive, to anyone who has seen python's asyncio or javascripts async/await APIs before. It simplifies using asio and increases compile times significantly by encouraging the usage of translations units. The features include: - coroutine types (eager, lazy, generators) - built-in cancellation - synchronization of multiple coroutines (select, gather, join) - channels - with (an async scope akin to python's with expression) - asio integration, i.e. completion tokens I think this kind of library is much needed in boost and the wider C++ community. code: https://github.com/klemens-morgenstern/async docs: https://klemens.dev/async/

11 31

Request to merge a fix to Boost.Core
by Peter Dimov 26 Jul '23

26 Jul '23

May I please merge the following fix https://github.com/boostorg/core/commit/c7134904e27237dbbb81ba28f0f23fc365b… to address issue https://github.com/boostorg/core/issues/150 ? I can't verify that the fix actually works, but it doesn't affect non-Android platforms, so can't make things any worse.

2 1

Re: [boost] Request to merge bug fixes in Boost.Outcome
by Niall Douglas 25 Jul '23

25 Jul '23

On 20/07/2023 11:36, Niall Douglas wrote: > Can I get permission to merge a few small bug fixes plus docs fixes? > > https://github.com/boostorg/outcome/commits/develop > > 1. Changes just before the beta window breaks build on C++ 14 in certain > corner cases, fixed. > > 2. Experimental Outcome Boost result did not compile due to changes to > status code by LEWG, fixed. > > 3. Docs fixes also due to the LEWG renaming breaking docs examples. > > 4. Failure to compile Experimental Outcome on FreeBSD fixed. Ping on the above. Niall

2 2

Bug fixes in Boost.URL
by Alan de Freitas 21 Jul '23

21 Jul '23

I would like to ask for permission to merge the following bug fixes to master in Boost.URL: - c97bc278: parse_query does not recreate string_view - 0ca58467: url_view string_view constructor requires non-url_view_base - f2bb191b: IP-literal can be IPv6addrz Thanks -- Alan Freitas https://alandefreitas.github.io/alandefreitas/ <https://github.com/alandefreitas>

2 1

Request to merge bug fixes in Boost.Outcome
by Niall Douglas 20 Jul '23

20 Jul '23

Can I get permission to merge a few small bug fixes plus docs fixes? https://github.com/boostorg/outcome/commits/develop 1. Changes just before the beta window breaks build on C++ 14 in certain corner cases, fixed. 2. Experimental Outcome Boost result did not compile due to changes to status code by LEWG, fixed. 3. Docs fixes also due to the LEWG renaming breaking docs examples. 4. Failure to compile Experimental Outcome on FreeBSD fixed. Niall

2 1

boost::normal_distribution<>(boost::mt19937) changed behavior from 1.60 to 1.80
by Foelsche, Peter 18 Jul '23

18 Jul '23

Dear All, I'm not certain if the behavior I'm seeing is expected or a problem. I'm getting different series of numbers from the two different boost versions in question. When running a diff on the output I'm getting numbers inserted in one series or the other and then the two series become identical again. Below is the source. I'm using the following series of commands: g++ -std=c++14 test.cpp -g -DNDEBUG -fwhole-program -I/mnt/share/boost/boost-1.80/include -o 180 g++ -std=c++14 test.cpp -g -DNDEBUG -fwhole-program -o 160 ./180 16384 2078781393 1 > 180.txt ./160 16384 2078781393 1 > 160.txt diff 160.txt 180.txt |more The first difference is at line 284. The next at 364, 1783, 2685. Peter PS. g++ (GCC) 5.3.0 PPS. The source #include <boost/random.hpp> #include <boost/version.hpp> //#include <boost/random/variate_generator.hpp> #include <boost/random/mersenne_twister.hpp> #include <boost/random/normal_distribution.hpp> #include <boost/random/uniform_int_distribution.hpp> #include <limits> #include <iostream> int main(int, char**argv) { std::cout << BOOST_LIB_VERSION << std::endl; const auto bOld = std::atoi(argv[3]) != 0; boost::mt19937 sGenerator; sGenerator.seed(std::atoi(argv[2])); //boost::random::uniform_int_distribution<> sDist(0, std::numeric_limits<int>::max()); boost::normal_distribution<> sDist(0.0, 1.0); boost::variate_generator<boost::mt19937, boost::normal_distribution<> > sGen(sGenerator, sDist); for (int i = 0, iMax = std::atoi(argv[1]); i < iMax; ++i) if (bOld) std::cout << sDist(sGenerator) << std::endl; else std::cout << sGen() << std::endl; }

2 1

Boostorg GitHub now has unlimited private repositories and collaborators
by Glen Fernandes 17 Jul '23

17 Jul '23

Boostorg GitHub now has unlimited private repositories and collaborators. Glen

1 0

Request to fix docs mistake in Boost.Outcome
by Niall Douglas 16 Jul '23

16 Jul '23

I know the beta release is happening, but when it's out and master branch is reopened can I get permission to merge a mistake in documentation fixed by https://github.com/ned14/outcome/issues/280? Niall

4 8

[1.83][type_erasure] Permission to merge to master
by Joaquín M López Muñoz 14 Jul '23

14 Jul '23

Hi, I’d like to merge this to master: https://github.com/boostorg/type_erasure/compare/master...develop This is a fix for issue #20: https://github.com/boostorg/type_erasure/issues/20 Plus some CI machinery kindly provided by Peter Dimov. Tests pass 100% on develop. Thank you, Joaquín M López Muñoz

2 1

[Release] Master branch is closed for beta
by Marshall Clow 13 Jul '23

13 Jul '23

Master is closed for all changes. See the release schedule at: https://www.boost.org/development/index.html <https://www.boost.org/development/index.html> -- Release managers

2 3

[release] Boost 1.83.0 beta 1 released
by Marshall Clow 13 Jul '23

13 Jul '23

Boost release 1.83.0 beta 1 is now available at: https://boostorg.jfrog.io/artifactory/main/beta/1.83.0.beta1/source/ The SHA256 checksums are: 69fe7224568acfa5491bfaa04fd522bf7cfca1800aa192de96ce560da714902f boost_1_83_0_b1.7z 49afc7c20d65949f7b775060bbec403e7e81d207949dd9f412e2d4569ea5d3f7 boost_1_83_0_b1.zip fe3895ee9ac78cf57328415f1b3bf3da7ea2ccb3ad87bf0d9b720910d99d18ae boost_1_83_0_b1.tar.bz2 fbbe0d439db5b65f194eb61b89b5cda0575387b0b23fbb85900c3c9ef9eb64bf boost_1_83_0_b1.tar.gz There was one bug reported during the beta process; Boost.Context does not build on ARM64 systems. This will be fixed for the final release. If you want to fix it locally, edit the file libs/context/build/Jamfile.v2: - else if [ os.platform ] = "ARM" { tmp = aapcs ; } + else if [ os.platform ] in ARM ARM64 { tmp = aapcs ; } The web site has not yet been updated (tomorrow, I hope) but when it is, the release notes will be at: https://www.boost.org/users/history/version_1_83_0.html Please try the beta and report any problems you encounter. Thanks to everyone who contributed to the release. -- Boost Release Team

1 0

New Website Clarification
by Vinnie Falco 11 Jul '23

11 Jul '23

In this recent reddit post, Jonathan (online nickname "foonathan") says: > AFAIK the CppAlliance decided to unilaterally write a > new boost website for the Boost foundation, but the Boost > foundation wasn't/isn't that interested in it. > ... > I was told details, but I don't know whether they are official > Boost foundation statements or personal views of the person > that told me about it, so I don't want to share them. https://www.reddit.com/r/cpp/comments/14whxvd/comment/jriii9h/ I responded with a clarification which I am reposting here for the convenience of the folks on the mailing list. Cut on the dotted line: Thanks ---- Point of clarification here: We (a collection of Boost library authors including myself) recognized the need for an updated website. Discussions about a new website would recur on the mailing list, with everyone offering different opinions. There were one (maybe two? efforts to produce a new website which started out with good intentions but ultimately failed for various reasons (venturing a guess I would say that it was a "design by committee" problem combined with a lack of resources). The current new in-development website is here (the URL is temporary): https://boost.revsys.dev Please open any issues or requests in the corresponding site repo: https://github.com/cppalliance/temp-site Because I care about Boost and I am deeply committed to improving the C++ ecosystem, I decided that The C++ Alliance would invest its resources in a new website project, following these principles: That we would start building the site first instead of starting with lengthy mailing list discussions that go nowhere. That the new site would be designed according a vision that was later outlined in a mailing list post (see: https://lists.boost.org/Archives/boost/2023/05/254612.php) *After* the site was substantially completed we would launch a public beta to get feedback on what areas we need to work on. That we would leave to the Boost community: the library authors, maintainers, reviewers, release managers, and users; the decision on whether the new website is what they want to represent Boost going forward. In other words I took the approach to simply build it first and then figure out what people want later. Because the mailing list tradition is to debate a thing intensely and then proceed to do nothing as no one is interesting in actually doing the work. Of course I recognized and accepted before the project was started that this could be one huge gamble; that no one is going to want this type of site, and that most everyone prefers the existing site. I can understand the Boost Foundation's reluctance to embrace this new website. Creating, maintaining, and hosting something of this high level of quality requires resources. Fortunately, The C++ Alliance is well equipped for the task. To ensure the ongoing success of this website we have allocated in our budget ongoing full-time staff as well as the resources to ensure that the website is performant for visitors in every timezone (as Boost has a global audience). Our dedicated website staff includes: Samuel Darwin: Our full-time CTO/Senior DevOps expert. He is the guy who deployed Drone CI and make it available for the entire Boost GitHub organization (example: https://drone.cpp.al/boostorg/url) He brings decades of experience managing live systems and has been studying intensely on the specific needs of C++ developers Spencer Strickland: Our full-time front-end developer who is up-to-date on modern, responsive website development. He is also a programming enthusiast who loves writing JavaScript and Python programs. He is also working on styling the templates for the new documentation toolchain (example: https://www.boost.revsys.dev/doc/user-guide/task-networking.html) Peter Turcan: Our full time technical writer. He's furiously typing away at brand new documentation for Boost users and authors. As documentation complaints are a recurring theme from users, we feel that having at least one dedicated technical writer is probably a good start! You can check out his work here: https://www.boost.revsys.dev/doc/contributor-guide/version-control.html We also keep an ongoing maintenance contract with RevSys (https://www.revsys.com/) a wonderful development company whose founder (Frank Wiles) specializes in Django and is also responsible for contributing a huge percentage of the work that went into the Django project itself. Only the best for Boost! And don't forget you can visit all of us at The C++ Alliance, plus many Boost library authors, maintainers, and users, and many prominent members of the C++ community including some Standardization Committee regulars, by joining the Official C++ Language Slack Workspace at: https://cppalliance.org/slack/ The C++ Alliance sponsors this workspace by offering a complete Paid Plan which allows unlimited full history, uploads, video and audio recordings, and video and audio huddles/group chats for collaboration and more. Visit us today!

2 1

Boost Foundation - a few updates
by David Sankel 10 Jul '23

10 Jul '23

Hey all, I wanted to give a few updates on Boost Foundation happenings. First, for those who aren't aware, we're the 100% volunteer-led 501(c)3 non-profit behind boost.org, the C++Now conference, and the Boost C++ standardization effort. We originally were the Boost Steering Committee under the Software Freedom Conservancy, but a couple of years ago formed our own non-profit. We meet monthly (you can see our minutes here <https://docs.google.com/document/d/1zMKUX3nfdcOXT6nUIU4M_YRlCU4ywGoG40ouo3I…>) and our mission is library development, C++ standard enhancements, and best practices (more about that on our quite ugly website <https://sites.google.com/a/boost.org/steering/>). Annually at C++Now, we elect directors to the Boost Foundation board. This May we added three members to the roster: - *Kristen Shaker. *Kristen, hailing from Google, has jumped in and contributed heavily to the board over the past year. She joined our Code of Conduct team, was a major contributor in our most tricky cases, and helped interfacing with our lawyer. She has also used her extensive network and taken charge of moving our boost.org rackspace account to AWS. Kristen is an enthusiastic doer and I'd very much love to see what she does in a Boost Foundation director role. - *Inbal Levi.* Inbal is one of those who came to C++Now and immediately fell in love with the conference. She now serves as the conference's program chair, and it only takes a little browsing of this year's program to see what a fantastic job she's done. Inbal brings a lot of experience to the table as well: she is a co-founder of the Core C++ conference which is now one of the biggest in the world; and she sits on the board of the C++ Foundation. I think Inbal's experience, network, and passion will be a great asset to the board. - *Jeff Garland*. Jeff is a long-time Boost author and contributor. He's also been highly active this past year in the Foundation. He created and led our C++ standardization initiative and has grown it to over a dozen members. Jeff's input is essential in revitalizing our Boost libraries effort and think he will be a solid contributor to the board. There are a few ongoing initiatives that I'm excited to call out: - *Server cost reduction.* We currently have a heavy monthly cost for both the mailing list and the boost.org server. These used to be free, but vendors have started charging non-profits for this kind of service. We've been upgrading the website to a newer version of PHP which will enable a cost-saving move to AWS. Kristen has been doing a fantastic job leading this effort. We also, with huge lifting from Sam Darwin, moved our mailing lists from mailgun to SES. This unfortunately broke threading so we moved back. :( - *discourse.boost.org <http://discourse.boost.org>.* We've been getting an experimental discourse.boost.org forum up and running. Many other Open Source communities have moved to discourse (see discourse.llvm.org and users.rust-lang.org for a couple examples) and it looks like a great tool. We like the idea that an online forum lowers the barrier to joining our community, especially for Millennials and Gen Z. We also like the benefits of using popular Open Source software rather than something home grown that we'd have to maintain. So, we'll try it out. If it turns out to be awful, we'll take it down. - *Boost engagement*. Jeff Garland is leading a subcommittee that is trying to figure out ways to get more engagement in Boost, both from user and author perspectives. There's been a lot of great ideas thrown around, but it's still too early to say what this is going to look like. To be sure, there'll be more to report on here as time goes on. That's all for now. If you have any questions feel free to reply to this thread or ask me directly. Cheers, David Sankel Boost Foundation Executive Director

3 3

Full-Text Search is LIVE!
by Vinnie Falco 10 Jul '23

10 Jul '23

Greetings. I am proud to announce that Mohammad’s excellent work on implementing a full-text search which looks into all the Boost libraries and their documentation is now complete, and has been published to the live website. You can access the search by pressing the Search button in the top right of the page: https://boost.org Please note that this is only the first iteration of this search tool and as such it will probably not give the perfect results that everyone expects every time. But now that we have something in place we can feedback, brainstorm on how to make it better, and iterate on it so that it evolves into something that consistently enhances the Boost user experience. To report problems or suggestions related to the search including the user interface, and the indexed contents, please open an issue in the Boost website repository: https://github.com/boostorg/website/issues There is also a “Report Issue” button in the search UI. Thanks!

1 0

Search Functionality Now Available on beta.boost.org
by Mohammad Nejati [ashtum] 09 Jul '23

09 Jul '23

Hey everyone, We have added search functionality to beta.boost.org. Currently, a search button appears on each library's documentation page and generic pages like https://beta.boost.org/doc/libs/. When users are browsing a specific library page, the search box will have a limited scope for that specific library's documentation. However, on generic pages, it will search across all libraries. Once we ensure its stability and user-friendly experience, we look forward to incorporating it into the main website. If you have any suggestions or encounter any issues while using the search functionality, please reply to this email. Your feedback will greatly assist us in refining the search feature and ensuring it meets the needs of Boost users. Respectfully Yours, Mohammad Nejati ---- C++ Alliance Staff Engineer

5 12

[release] Boost 1.83.0 Beta 1 Release Candidate 1 is available
by Marshall Clow 08 Jul '23

08 Jul '23

Available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.83.0.beta1/source/> The SHA256 checksums are as follows: 69fe7224568acfa5491bfaa04fd522bf7cfca1800aa192de96ce560da714902f boost_1_83_0_b1_rc1.7z 49afc7c20d65949f7b775060bbec403e7e81d207949dd9f412e2d4569ea5d3f7 boost_1_83_0_b1_rc1.zip fe3895ee9ac78cf57328415f1b3bf3da7ea2ccb3ad87bf0d9b720910d99d18ae boost_1_83_0_b1_rc1.tar.bz2 fbbe0d439db5b65f194eb61b89b5cda0575387b0b23fbb85900c3c9ef9eb64bf boost_1_83_0_b1_rc1.tar.gz 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 Release Managers

4 9

Reminder: Master branch closes for the 1.83.0 Beta release TODAY!
by Marshall Clow 05 Jul '23

05 Jul '23

Don’t say we didn’t warn you…. As always, you can find the calendar at: https://www.boost.org/development/index.html — The release managers

1 0

[release 1.83][flyweight] permission to merge
by Joaquin M López Muñoz 01 Jul '23

01 Jul '23

Hi, Not sure I need to request explicit permission, but in any case I'd like to merge the following commits on flyweight/develop to flyweight/master: https://github.com/boostorg/flyweight/commit/3dc485bfe8726eabebf7c0f055cadc… https://github.com/boostorg/flyweight/commit/137686b0baee3d1a048bf2a2776c0a… https://github.com/boostorg/flyweight/commit/e9f326b1adf0ed825bc7ff10b3f832… This solves the following issue, which is in fact a regression: https://github.com/boostorg/flyweight/issues/12 Thank you, Joaquín M López Muñoz

2 2

Reminder: Master branch is closing for the 1.83.0 beta release this WEDNESDAY (5-July)
by Marshall Clow 01 Jul '23

01 Jul '23

As always, you can find the calendar at: https://www.boost.org/development/index.html — Marshall

1 0

on windows flyweight simple_locking is using std::mutex but it should be using std::recursive_mutex()
by Foelsche, Peter 30 Jun '23

30 Jun '23

Dear All, On windows flyweight simple_locking is using std::mutex but it should be using std::recursive_mutex. I've got this firing an exception due to _Check_C_return() getting passed something else than success (number 3). I've checked by implementing my own locking policy and it definitely shows that the code is attempting to hold more than a single lock in parallel on the same mutex. The secured set.erase() can cause further flyweights to be destroyed given a suitable recursive use of flyweight. Kind Regards Peter Foelsche PS. Thanks for boost!

4 3

<stdfloat> support in Boost.Math
by Matt Borland 28 Jun '23

28 Jun '23

Today support was added for C++23’s <stdfloat> types in Boost.Math. Please let us know if you run into any warnings or errors as we go through the release captures, and betas in the following weeks. There are two common issues that we found. The first is a stack overflow in GCC 13.1 from their internal type promotion system. This will be fixed in 13.2, and we have added workarounds for it. The second are warnings and errors from implicit conversions between types. We have fixed hundreds of instances of these throughout the code base. Thank you for your help as always. Matt

1 0

Fernando Pelliccioni joins The C++ Alliance
by Vinnie Falco 28 Jun '23

28 Jun '23

I am pleased to announce that Fernando Pelliccioni has joined The C++ Alliance to become a full time contributor to Boost. This brings us to a total of 10 Staff Engineers working in C++, and 4 staff doing other work. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

1 0

Regarding the MySQL and Redis formal reviews
by Vinnie Falco 28 Jun '23

28 Jun '23

Dear All, This is a brief update on some pertinent developments. Foremost, I want to acknowledge the exceptional contributions of Ruben Perez, creator of Boost.MySQL, and Marcelo Silva, the author of Boost.Redis. Their hard work in developing and refining their respective Boost libraries exemplifies the best qualities of authorship. They are actively engaged in the various channels of the public C++ Slack Workspace (https://cppalliance.org/slack/) collaborating and answering questions. Consider joining. To clarify a potential misunderstanding, Ruben joined the C++ Alliance team only after his library Boost.MySQL was accepted. Therefore, his subsequent affiliation had no bearing on the outcome of the review. Regarding Marcelo, he has always worked independently on Boost.Redis and has no contractual relationship with The C++ Alliance. Next, I'd like to laud Klemens for his unwavering diligence. As the review manager for these two libraries, he operates with impartiality and independence from the C++ Alliance with no financial recompense. The C++ Alliance policies precludes any author sponsored by us from acting as a review manager for a library that we also sponsor. This policy underscores our belief and commitment to the effectiveness and integrity of the Boost Formal Review process. In conclusion, our objective has always remained consistent: to fortify and expand Boost, and to support the author and maintainer community. The talent, dedication, and hard work invested in making Boost the best it can be is truly commendable. Our motivation is driven by passion for the language and open source. Together, we can make Boost even more remarkable. Yours sincerely, Vinnie

1 0

Reminder: The deadline for "major changes" for Boost 1.83 is TOMORROW, 6/28
by Marshall Clow 28 Jun '23

28 Jun '23

As always, you can find the calendar at: https://www.boost.org/development/index.html — Your friendly release manager

1 0

Adding Search Functionality to boost.org
by Mohammad Nejati [ashtum] 27 Jun '23

27 Jun '23

Hey everyone, One of the issues with the current Boost website is the absence of search functionality. This forces users to rely on search engines and use queries like `site:boost.org asio cancellation_slot` However, this approach has several problems. Firstly, it often displays outdated versions in the search results. Secondly, it lacks a proper hierarchical presentation to effectively guide users. Moreover, there is no way to filter the results for a specific library. To address this problem quickly, we have decided to create a search index for the existing HTML documents on the Boost website. However, we encountered a primary challenge during this process. We needed to extract contents with the correct hierarchy for each library to ensure that the search results were displayed in a hierarchical manner. For instance, the results will be shown as `Asio › Reference › Deferred_values › Requirements` This hierarchical presentation can significantly enhance the user experience. The Boost libraries utilize various documentation formats such as QuickBook, AsciiDoc, Doxygen, and even multiple handwritten formats. This diversity posed a challenge in creating a generic crawler script. To overcome this obstacle, we initiated the Boost.Gecko project. This project involved the development of 16 custom crawlers, tailored to extract search records from the 151 Boost libraries. We are currently utilizing the Algolia search platform to index search records, which offers a free plan for open-source projects. Algolia also provides a rich JavaScript library for building a search interface on the frontend. We have leveraged this library to design a customized user interface for the search box, enhancing the navigation of search results. I kindly request you try out the new search functionality by visiting the demo page at: https://cppalliance.org/boost-gecko/ and share your thoughts, suggestions, or any issues you may encounter. Your input will greatly assist us in refining the search feature and ensuring it meets the needs of our users. Please note that the drop-down for selecting a library is included to simulate the experience of being on a specific library page. Our plan is to incorporate a search button into the header of every library page, defaulted to search within that specific library. Demo page: https://cppalliance.org/boost-gecko/ Repository: https://github.com/cppalliance/boost-gecko/ Respectfully Yours, Mohammad Nejati ---- C++ Alliance Staff Engineer

5 8

conversion of csv to pdf file
by Daggumati, Rajesh 26 Jun '23

26 Jun '23

Hi Team, As per project requirement, we need to convert .csv file to pdf file. Do we have any library to convert .csv file to pdf in boost Please let me know if we have any. Regards, Rajesh D Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment. Confidential - Company Proprietary

1 0

Adding 'indirect_sort' to boost::algorithm
by Marshall Clow 26 Jun '23

26 Jun '23

At Boostcon last month, there was a discussion of indirect sorting algorithms to boost::algorithm. An “Indirect sort” (called 'argsort' in numpy - https://numpy.org/doc/stable/reference/generated/numpy.argsort.html) returns a sequence of indices into the collection describing how the collection can be rearranged in order to become sorted. So I created https://github.com/boostorg/algorithm/pull/117 to start down this road. (There’s clearly more that could be done here - stable_sort, partial_sort, nth_element, etc) Comments welcomed. — Marshall

6 8

Boost.Pool regression: purge_memory() causes initial size to double on subsequent allocation
by Joel Hock 21 Jun '23

21 Jun '23

951ca5725 changed malloc_need_resize() to use set_next_size(), which sets start_size in addition to setting next_size. this causes repeated use of purge_memory() to allocate 2x size after every use. as illustration: >>>>>>>>>>>>>>>>> #include <boost/pool/pool.hpp> int main() { boost::pool pool(8); for(int i = 0; i < 10; i++) { printf("%d %ld\n", i, pool.get_next_size()); pool.purge_memory(); void *ptr = pool.malloc(); (void)ptr; } } <<<<<<<<<<<<<<<<< before the commit the output is: 0 32 1 64 2 64 3 64 4 64 5 64 6 64 7 64 8 64 9 64 after the commit, the output is: 0 32 1 64 2 128 3 256 4 512 5 1024 6 2048 7 4096 8 8192 9 16384

1 0

Boost Storytellers: Unordered
by Christian Mazakas 21 Jun '23

21 Jun '23

Hey everyone, I figured I'd take some time to talk about Unordered and where it's at. At the time of writing, Unordered's develop branch has been updated to include a new container: `boost::concurrent_flat_map`. A high-level description of the container and its algorithms can be found here: https://www.boost.org/doc/libs/develop/libs/unordered/doc/html/unordered.ht… It's been an honor and a privilege to develop alongside our own Joaquín M López Muñoz and Peter Dimov. While the advancements done to the algorithms themselves are note-worthy, what's not often talked about is taming implementation complexity. After all, algorithms don't mean much until they're translated to code. Boost.Unordered offers several different containers, all each a similar flavor of one another. The broad categorization is closed-addressing containerss, open-addressing containers and finally the concurrent containers, which are in actuality a subset of the open-addressing ones. The closed-adressing (CA) containers are the most straight-forward to abstract over as an `unordered_map` and `unordered_multimap` only differ in terms of how insertion is performed. Internally, the CA containers simply wrap a `table` struct that's templated over a Types policy-like which is used for pulling relevant typedefs from. Though I must confess, the `table` itself does contain myriad member functions such as `equals_unique` and `equal_equiv` which are used when comparing the tables themselves via `operator==`. The open-addressing (OA) containers are spiritually similar to the CA containers in that they wrap a simple common table type with a type policy template parameter used for pulling typedefs from in the relevant spots. But what makes the OA containers a good bit more nuanced is that there's both a `unordered_flat_map` and a `unordered_node_map`. The implementation complexity increases a good amount here. The CA containers all operate in terms of a simple `node`-like type that contains the appropriate `value_type` but the OA containers must abstract away a good bit more. The flat OA containers store their `value_type`s directly in a contiguous allocation so that lookup operations benefit from spatial locality in addition to being much more simple to manage from an implementation perspective. To support `unordered_node_map`, we have to update the type that's stored to be a `unique_ptr`-like. This essentially further extends the type policies already used by the containers to abstract over the storage type, the actual value type and how those values are accessed from a pointer to the storage type. This includes construction, destruction and dereferencing. The concurrent map adds yet another layer of abstraction but this time, in a much different spot and required a much larger holistic refactor of the codebase. The fundamental differences in container types require abstracting over how the table reads and inserts elements itself so we introduce an extra table layer. Previously there was but a single table type that supported all of the OA containers but now there's two table types that instead wrap a common `table_core` which contains common table primitives. The `concurrent_table` is responsible for managing its own locking schemes and then dispatches internally to its `table_core` and similarly for the `table` used by the non-concurrent containers. The OA containers are essentially implemented in 3 layers with the `table_core` being the lowest layer and the user-facing containers as the highest, with the specific middle layer being responsible for managing atomicity for the concurrent map and for providing things like iterators for the flat/node containers (the concurrent map offers no iterators). On paper it sounds relatively complex but in practice, navigating the code with this kind of foresight is easy and straight-forward, even more so now that GitHub's UI allows you to view and jump to struct definitions. Taming such implementation complexity into a neat and organized set of traits was definitely something beyond my skilset so I'm happy Joaquin was able to navigate such waters and I have a humbled understanding of policy-based design and how powerful it can be when applied properly. There's a couple of other things to note about the implementation that Boost authors may like. One is that we do allocator-aware constrution of a stack-local in emplace(). This is so that we can avoid a heap-allocation when doing lookup in the node-based OA containers. Originally, we actually didn't allocator-construct the stack-local but this turned out to be wholly incorrect because we'd move the stack-local to the heap when the key wasn't present in the container. This could lead to subtle bugs like not passing the memory resource when a user is using `std::pmr`. Another interesting aspect is that we recently updated the `erase(const_iterator)` method of the OA containers to return a proxy type. For performance reasons, the signature was originally `void erase(const_iterator)` but users found this cumbersome and annoying to work with as they'd often times swap containers entirely via a typedef. We now return a proxy type that lazily increments the internal iterator via implicit conversion to the container's iterator type. To this end, we're able to essentially have our cake and eat it too at the cost of making always-auto subtly confusing. I'm more than happy to talk about any other implementation strategies or answer questions if anyone is interested in the nitty gritty and can offer potential optimizations. - Christian

1 0

Re: [boost] charconv for C++11
by Gero Peterhoff 05 Jun '23

05 Jun '23

Hi Matt, thanks for your efforts. I have a few questions though: - Will charconv be included in boost 1.83 or which release is planned ? - Could you still include support for C++23 FP types (std::floatN_t) ? - Would it be possible to implement the FP functions constexpr ? thx & regards Gero

2 1

Windows Develop Regression Tests Failing - Boost Build?
by Tom Kent 04 Jun '23

04 Jun '23

When trying to run the regression tests for the develop branch from windows, I'm getting the following error: C:/teeks99-09/run/boost_bb/src/build\project.jam:284: in find-jamfile from module project error: Unable to load Jamfile. error: Could not find a Jamfile in directory '../../C:/teeks99-09/run/boost_root'. error: Attempted to find it with pattern '[Bb]uild.jam [Jj]amfile.v2 [Jj]amfile [Jj]amfile. [Jj]amfile.jam'. error: Please consult the documentation at 'https://www.bfgroup.xyz/b2/'. C:/teeks99-09/run/boost_bb/src/build\project.jam:347: in load-jamfile from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:64: in load from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:105: in load-used-projects from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:75: in load from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:134: in load-parent from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:538: in initialize from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:373: in load-jamfile from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:64: in load from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:167: in project.find from module project C:/teeks99-09/run/boost_bb/src\build-system.jam:618: in load from module build-system C:/teeks99-09/run/boost_bb/src/kernel\modules.jam:294: in import from module modules C:/teeks99-09/run/boost_bb/src/kernel/bootstrap.jam:135: in module scope from module It looks like the last good run I had was on march 11, which corresponds to the same day as this commit to that project.jam: https://github.com/boostorg/build/commit/fda357a8f55a08535afff0a11eec50fca1… That file doesn't mean much to me, is it possible it is causing the issue? Thanks, Tom

3 4

Moving sp_thread_pause, sp_thread_sleep to Core
by Christian Mazakas 02 Jun '23

02 Jun '23

Unordered's concurrent flat map contains a hand-rolled spinlock (graciously provided by Peter Dimov) but it contains a dependency on SmartPtr for the following two headers: #include <boost/smart_ptr/detail/sp_thread_pause.hpp> #include <boost/smart_ptr/detail/sp_thread_sleep.hpp> I advocate that we move these to Core. They're small, self-contained and are useful in broader contexts. Anyone have thoughts or objections? - Christian

5 14

git hub discussions.
by Robert Ramey 31 May '23

31 May '23

As an experiment, I've added to github discussions for the safe_numerics library. The idea is to provide a place for feedback from users of the library. I'd be curious to hear other persons thoughts on this. https://github.com/boostorg/safe_numerics/discussions/133 Robert Ramey

4 5

Re: [boost] Boost.Compat
by Peter Dimov 31 May '23

31 May '23

Ruben Perez wrote: > > So my suggestion is to create a separate library/repo, Boost.Compat > > (boostorg/compat, namespace boost::compat) for them. > > > > Thoughts? (Be sure to read the discussion in the PR as well.) > > > > I'm in favor of this. I agree with not allowing extensions, too. > > I think a light review should take place before inclusion. The suggested repository is now ready for light review at https://github.com/boostorg/compat, complete with its first component, an implementation of std::latch by Christian Mazakas. Everyone's light reviews are welcome.

6 13

Sam review scheduled
by Ruben Perez 20 May '23

20 May '23

Hi all, I'm happy to announce that the Sam library, featuring asio-based synchronization primitives, is being proposed for Boost inclusion. Repo: https://github.com/klemens-morgenstern/sam Docs: https://klemens.dev/sam/ The library is being proposed by Klemens Morgenstern. The review will take place between May the 29th (Monday) and June the 8th (Thursday). I will be managing the review. Boost.Sam offers async asio-based synchronization primitives, similar to standard mutex, condition_variable, semaphore and barrier. It's geared towards library writers that require fine-grain control over their synchronization operations. You can contact both me and the author by mail or on the cpplang Slack. Kind regards, Ruben.

4 7

Re: [boost] boost 1.82.0
by John Maddock 16 May '23

16 May '23

On 16/05/2023 02:39, Prabhakar Bhatt via Boost wrote: > Hi All, > > Recently we upgraded to Boost 1.82.0. > > We compiled the boost as : > > ./bootstrap.sh > --with-libraries=filesystem,system,program_options,iostreams,log,regex,stacktrace,thread > --without-icu > > When we tried to use the regex library and build Avro product we are > getting following error: > > Boost/boost_1_82_0/include/boost/regex/v4/cpp_regex_traits.hpp:1117: > undefined reference to > `boost::scoped_static_mutex_lock::scoped_static_mutex_lock(boost::static_mutex&, > bool)' > > Please can you help us in addressing the issue. Regex is now header only, *unless* you are building with a C++03 compiler (which is now deprecated), and will require linking to the external libboost_regex. John.

1 0

Re: [boost] Determine socket is ipv4 or ipv6
by Gavin Lambert 16 May '23

16 May '23

On 16/05/2023 15:26, Tarun Batra wrote: > I have a code something like this: > > TcpConnection::pointer my_conn = GetConn(req); > > tcp::socket& my_socket = my_conn->getSocket(); > > tcp::resolver my_resolver(my_socket.get_executor()); > > > Is it possible to check if the my_socket is ipv4 socket or ipv6 socket? That depends exactly what you mean by that, but you're likely looking for something like: my_socket.remote_endpoint().address().is_v6() Doxygen doesn't do a very good job at navigating the type templates involved here; using your IDE's code completion is more successful.

1 0

Reference section of Boost.Any leads to Boost.PFR
by Antony Polukhin 15 May '23

15 May '23

Hi, Just noted that clicking on "->" arrow at the developer preview of Boost.Any https://www.boost.org/doc/libs/develop/doc/html/any/ValueType.html leads to Boost.PFR reference section. No idea how is that possible. I'd appreciate help

1 0

boost 1.82.0
by Prabhakar Bhatt 15 May '23

15 May '23

Hi All, Recently we upgraded to Boost 1.82.0. We compiled the boost as : ./bootstrap.sh --with-libraries=filesystem,system,program_options,iostreams,log,regex,stacktrace,thread --without-icu When we tried to use the regex library and build Avro product we are getting following error: Boost/boost_1_82_0/include/boost/regex/v4/cpp_regex_traits.hpp:1117: undefined reference to `boost::scoped_static_mutex_lock::scoped_static_mutex_lock(boost::static_mutex&, bool)' Please can you help us in addressing the issue. Thanks and Regards, Prabhakar

1 0

Determine socket is ipv4 or ipv6
by Tarun Batra 14 May '23

14 May '23

Hi, I have a code something like this: TcpConnection::pointer my_conn = GetConn(req); tcp::socket& my_socket = my_conn->getSocket(); tcp::resolver my_resolver(my_socket.get_executor()); Is it possible to check if the my_socket is ipv4 socket or ipv6 socket?

1 0

Re: [boost] BOOST 1.82.0 with c++17
by Vinnie Falco 13 May '23

13 May '23

On Sat, May 13, 2023 at 5:52 AM Daggumati, Rajesh via Boost <boost(a)lists.boost.org> wrote: > Does boost 1.82.0 compatible with C++ 17 compiler? Check the bottom of this page: https://www.boost.org/users/history/version_1_82_0.html Thanks

1 0

BOOST 1.82.0 with c++17
by Daggumati, Rajesh 13 May '23

13 May '23

Hi Team, As per project requirement , we are going to upgrade to BOOST(1.82.0) and Qt(6.5 LTS) in our project. QT 6.5 LTS needs C++ 17 compiler. Does boost 1.82.0 compatible with C++ 17 compiler? Kindly please let us know your response. Regards, Rajesh D Confidential - Company Proprietary Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.

1 0

Please remove me from this list
by Vitaly Budovski 12 May '23

12 May '23

The web and email unsubscribe methods do not seem to work.

1 0

Version of RapidXml used in boost
by Kacvinsky, Tom 12 May '23

12 May '23

Hi, I am trying to track down with version of RapidXml is used in Boost 1.78.0. I don't have a problem with the RapidXml license attribution, but I do need to know the specific version of it that is used in Boost for our attribution purposes (copyright year and version). >From what I can see from a git blame, RapidXml was added to Boost around 2007 by the author of RapidXml (Marcin). Does anyone have idea which version is used in Boost? Thanks, Tom

1 0

Re: [boost] New Website !
by Ion Gaztañaga 12 May '23

12 May '23

On 11/05/2023 21:47, Vinnie Falco via Boost wrote: > On Thu, May 11, 2023 at 11:36 AM Ion Gaztañaga via Boost > <boost(a)lists.boost.org> wrote: >> The release notes page seems hard to parse, though: >> >> https://www.boost.revsys.dev/releases/ > > Ahem... well, would you believe that me and Greg pulled that one out > from scratch from our collective arse just hours before the > announcement? > > In other words, it is a placeholder / design sketch. It will get a > proper treatment shortly (and be actually hooked up to the database by > the talented Lacey). Great! Ion

1 0

Re: [boost] charconv for C++11
by Matt Borland 12 May '23

12 May '23

> > Here's my full test case, built with VS 2022 17.6 Preview 7 x64 (note that x64 vs. x86 makes a HUGE difference to charconv). I didn't bother to compare the from_chars scenario (as MSVC doesn't use a highly optimized algorithm there; investigating Eisel-Lemire is on our todo list). > > Hope this helps, > STL > Stephan, Thank you for this. I can add benchmarks for Lemire’s algorithm vs. the current MSVC STL from_chars to see if it’s worth pursuing for your team. Matt

2 1

Re: [boost] charconv for C++11
by Ruben Perez 12 May '23

12 May '23

> > > What does charconv do? I need this in MySQL.

1 0

Re: [boost] charconv for C++11
by Matt Borland 12 May '23

12 May '23

> I also still think that whoever came up with that specification needs a > whap upside the head, but then I've never encountered a reason to print > a floating-point value in hex, so I assume there's some justification > for it. Gavin, Hexfloats are useful for comparison of numerical accuracy. We use them in the Boost.Math unit tests when outputting ULP distances. https://github.com/boostorg/math/blob/develop/test/math_unit_test.hpp#L136 Matt

1 0

Re: [boost] charconv for C++11
by Matt Borland 12 May '23

12 May '23

> On May 12, 2023, at 8:59 AM, Alexander Grund via Boost <boost(a)lists.boost.org> wrote: > > Am 12.05.23 um 02:52 schrieb Gavin Lambert via Boost: >> Mere moments ago, quoth I: >>>> Hex format will be of the form +1.0e2p+5. The integer part will >>>> always be 0 or 1. The exponent will be with a p instead of an e like >>>> in base 10 formats. >> (Also, FWIW, gcc fails to parse that with the leading +. And I >> couldn't even find any online calculators that understand this format.) > According to cppreference the floating point parser should not support it: > > "the plus sign is not recognized outside of the exponent (only the > minus sign is permitted at the beginning)" > > So I'd say that is a bug in Boost charconv given that it wants to be > as-if the standard one. > You two are correct that a value with a leading plus sign should be EINVAL rather than ignoring it during parsing. I opened an issue, and will address it. Matt

1 0

Re: [boost] charconv for C++11
by Alexander Grund 12 May '23

12 May '23

Am 12.05.23 um 02:52 schrieb Gavin Lambert via Boost: > Mere moments ago, quoth I: >>> Hex format will be of the form +1.0e2p+5. The integer part will >>> always be 0 or 1. The exponent will be with a p instead of an e like >>> in base 10 formats. > (Also, FWIW, gcc fails to parse that with the leading +. And I > couldn't even find any online calculators that understand this format.) According to cppreference the floating point parser should not support it: "the plus sign is not recognized outside of the exponent (only the minus sign is permitted at the beginning)" So I'd say that is a bug in Boost charconv given that it wants to be as-if the standard one.

1 0

Re: [boost] Extra file in boost serialization for 1.82.0
by Robert Ramey 12 May '23

12 May '23

On 5/11/23 9:15 PM, Robert Ramey via Boost wrote: > There is a little more to it than this though. Some time ago I modified > my usage of Git so that I have my development updates in the development > branch - so far so good. But then I noticed that all the same > information incremental files were repeated in the master branch. I > found this redundant, repetitive and confusing. So I took to using > "squash and merge" when incorporating the changes on the development > branch. This option is available on GitHub. This seemed to give me what > I wanted: a detailed history of development and a concise changes in the > history of releases. It seems that something is awry here as the "squash > & merge" option doesn't merge file deletions. When I catch up, I'll > look into this. > Note this this procedure has some effects which were unanticipated. a) when someone checks in a change into the master branch without telling me, it is wiped out by the next merger to master. At first I thought this was a bug, now I'm thinking this is more of feature as it takes a long time to track down cases where someone has made changes which leave the master permanently out of sync with the development branch. b) The development and master branches are always the same at the time of release. Again - a feature not a bug. c) Of course it probably does annoy he who checked in a change directly to master, but he shouldn't be doing that anyway. Robert Ramey

1 0

Re: [boost] Extra file in boost serialization for 1.82.0
by Glen Fernandes 12 May '23

12 May '23

On Thu, May 11, 2023 at 9:20 PM Marshall Clow via Boost < boost(a)lists.boost.org> wrote: > > On May 11, 2023, at 12:01 PM, Bryan St. Amour via Boost < > boost(a)lists.boost.org> wrote: > > > > Hi, > > > > I noticed that under boost/serialization, there is a file > "collection_size_type copy.hpp" (notice the space in the file name.) > Comparing it with the contents of collection_size_type.hpp, it looks like > "collection_size_type copy.hpp" is newer. Can someone verify which one is > the correct collection_size_type header file? > > This is https://github.com/boostorg/serialization/issues/237 < > https://github.com/boostorg/serialization/issues/237> > And https://github.com/boostorg/serialization/issues/221 < > https://github.com/boostorg/serialization/issues/221> > > Sadly, this has been a problem for several releases. > > Robert removed it from develop a while ago but it's still in master. Robert, your merges to master aren't removing the file, you need to fix your branches. Glen

2 1

Re: [boost] Extra file in boost serialization for 1.82.0
by Marshall Clow 12 May '23

12 May '23

> On May 11, 2023, at 12:01 PM, Bryan St. Amour via Boost <boost(a)lists.boost.org> wrote: > > Hi, > > I noticed that under boost/serialization, there is a file "collection_size_type copy.hpp" (notice the space in the file name.) Comparing it with the contents of collection_size_type.hpp, it looks like "collection_size_type copy.hpp" is newer. Can someone verify which one is the correct collection_size_type header file? This is https://github.com/boostorg/serialization/issues/237 <https://github.com/boostorg/serialization/issues/237> And https://github.com/boostorg/serialization/issues/221 <https://github.com/boostorg/serialization/issues/221> Sadly, this has been a problem for several releases. — Marshall

1 0

Re: [boost] charconv for C++11
by Gavin Lambert 12 May '23

12 May '23

Mere moments ago, quoth I: >> Hex format will be of the form +1.0e2p+5. The integer part will >> always be 0 or 1. The exponent will be with a p instead of an e like >> in base 10 formats. > This is some strange definition of "hex" with which I was previously > unfamiliar. > > It also contradicts itself, by saying "a p instead of an e" while the > example contains both. (And isn't a very good example, lacking actual > hex digits.) It later occurred to me that the "e" could be intended as a hex digit, thus "1.0e2 with exponent +5". This still makes it a poor example, though. It might perhaps be intended as an example of a vexing parse, but in that case it shouldn't be the *only* example (and perhaps should be elsewhere). (Also, FWIW, gcc fails to parse that with the leading +. And I couldn't even find any online calculators that understand this format.)

1 0

Re: [boost] charconv for C++11
by Gavin Lambert 12 May '23

12 May '23

On 12/05/2023 10:59, Peter Dimov wrote: > The work-in-progress documentation is here: https://develop.charconv.cpp.al/ > Hex format will be of the form +1.0e2p+5. The integer part will > always be 0 or 1. The exponent will be with a p instead of an e like > in base 10 formats. This is some strange definition of "hex" with which I was previously unfamiliar. It also contradicts itself, by saying "a p instead of an e" while the example contains both. (And isn't a very good example, lacking actual hex digits.) I've now found the reference to it -- https://en.cppreference.com/w/cpp/utility/to_chars says that "hex" uses as-if printf %a, and https://en.cppreference.com/w/cpp/io/c/fprintf says printf %a appears *somewhat* like the above (but I still think there is an error in the above). I also still think that whoever came up with that specification needs a whap upside the head, but then I've never encountered a reason to print a floating-point value in hex, so I assume there's some justification for it.

1 0

Re: [boost] charconv for C++11
by Peter Dimov 11 May '23

11 May '23

Robert Ramey wrote: > > In addition to all that, from/to_chars are standard C++17, so Charconv > > can be used by libraries that want to support C++11 (or 14) today, but > > at the same time want to be able to switch to the standard functions > > later when increasing the minimal supported standard to C++17. > > So this is an implementation in C++11 of a library which is already accepted > (and presumably shipping) in C++17 ? And the only user who would use this is > someone who has C++11 but can't upgrade to C++17? > Doesn't seem like very many people to me. Users... and library authors whose libraries still support C++11/14, such as Boost.JSON. > I didn't find an documentation for this. The work-in-progress documentation is here: https://develop.charconv.cpp.al/

1 0

Re: [boost] New Website !
by René Ferdinand Rivera Morell 11 May '23

11 May '23

On Thu, May 11, 2023 at 5:00 PM Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: > > Loading the page takes noticeably longer than the original website. Interesting.. For me, on Firefox 112.0.2 on Manjaro w/Plasma doing a full reload of the home pages is: boost.org.. 1.71s boost.revsys.dev.. 1.57s So the new site is faster for some reason? -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

2 1

Re: [boost] New Website !
by Vinnie Falco 11 May '23

11 May '23

On Thu, May 11, 2023 at 3:00 PM Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: > Just opening this page immediately starts hogging CPU on my system Consider opening an issue here https://github.com/cppalliance/temp-site/issues > Please, remove the animation. We are going to remove it as it was an earlier design element that no longer suits the revised style of the site. > Loading the page takes noticeably longer than the original website. I > understand that the new website is probably hosted on a weaker server, > but I also suspect that it is overall more heavy than the original website. Shouldn't take longer to load, this is a statically generated site except for a few dynamic pages (like the Libraries). However, we have also not put any efforts into optimizing page loads (that comes last). > The release notes (https://www.boost.revsys.dev/releases/) seems to have > broken formatting. Library names are not highlighted and release note > items are not displayed as list items. Yes well.. that's not a "real" page, we just slapped it together (see my earlier reply to Ion). > There are quite a bit of information missing. For example, Release > schedule (https://www.boost.org/development/index.html) and most of the > pages under the Development menu seem to be missing. Yes there is, that's why we are doing this open beta, and not meddling with the live website at boost.org. So that we can ensure nothing is missing, everything is accounted for, and all voices are heard. And probably I want to test it for at least one release - we would release both in the live site and in the new site, and see how the release goes in the new site, to ensure we don't miss a release because something is wrong with the new code. > PS: I'm using Firefox 113.0 on Kubuntu 22.04. Please include that information in the issues you open at https://github.com/cppalliance/temp-site/issues Thanks

1 0

Re: [boost] New Website !
by Andrey Semashev 11 May '23

11 May '23

On 5/11/23 17:35, Vinnie Falco via Boost wrote: > Hey, it’s Vinnie here again! I have some very exciting news to share > with you. The renovated website for Boost that we’ve been working on > for far too long is now going into its Public Beta phase! Feel free to > poke around and kick the tires but keep in mind this is a piece of > software and it is still under development. Some parts are missing, > incomplete,or buggy. Without further ado: > > https://boost.revsys.dev Just opening this page immediately starts hogging CPU on my system. I'm assuming, this is because of the animated logo on the right half of the screen. Please, remove the animation. I would also reduce the size of or even remove the logo entirely, as it wastes too much space. Loading the page takes noticeably longer than the original website. I understand that the new website is probably hosted on a weaker server, but I also suspect that it is overall more heavy than the original website. The release notes (https://www.boost.revsys.dev/releases/) seems to have broken formatting. Library names are not highlighted and release note items are not displayed as list items. There are quite a bit of information missing. For example, Release schedule (https://www.boost.org/development/index.html) and most of the pages under the Development menu seem to be missing. PS: I'm using Firefox 113.0 on Kubuntu 22.04.

1 0

Re: [boost] charconv for C++11
by Robert Ramey 11 May '23

11 May '23

This is the useful information I was hoping to get when I asked the question. Unfortunately, I had to dig a little deeper than I expected and have a few more questions: On 5/11/23 11:05 AM, Peter Dimov via Boost wrote: > Robert Ramey wrote: > lexical_cast can convert any streamable type to any other streamable type. > It's defined as `ss << input; ss >> output; return output;` where `ss` is > a default-constructed `std::stringstream`. Hmmm - cannot not an ss be associated with a local of choice via std::imbue? Looking at the documentation for lexical cast I don't see this. I'm not sure what the issues would be with this. > This has a number of implications. One, the conversion is locale-dependent. Hmmm - conversion to/from strings isn't locale dependent, how does one deal with string numeric formats which depend on locality - e.g. some countries use , while others use . as a decimal separator. > Two, for conversion to string, you use lexical_cast<std::string>, which can > allocate. There is a section in the lexical_cast docs titled "converting to string without dynamic memory allocation". Actually it would never occur to me that one could return a string from a conversion without a dynamic memory allocation. But I guess that's me. Three, errors are signaled via exceptions (although there's > try_lexical_convert that can avoid this.) Right > lexical_cast does a good job of optimizing the from_chars and to_chars > cases when it detects it can do so, but that by definition can't be better > than the programmer just calling the primitive operations from_chars > and to_chars directly, as they are (a) locale-independent, (b) non- > allocating, (c) non-throwing. OK > > In addition to all that, from/to_chars are standard C++17, so Charconv > can be used by libraries that want to support C++11 (or 14) today, but > at the same time want to be able to switch to the standard functions > later when increasing the minimal supported standard to C++17. So this is an implementation in C++11 of a library which is already accepted (and presumably shipping) in C++17 ? And the only user who would use this is someone who has C++11 but can't upgrade to C++17? Doesn't seem like very many people to me. I didn't find an documentation for this. May I presume that it's not deemed necessary as C++17 is documented and this is an exact equivalent? Note that there is another boost library, Boost.Convert, which purports to address short comings in lexical cast. https://www.boost.org/doc/libs/1_82_0/libs/convert/doc/html/index.html Has anyone looked at or evaluated this? Is there overlap? I actually never knew about this. Robert Ramey

1 0

Re: [boost] New Website !
by Vinnie Falco 11 May '23

11 May '23

On Thu, May 11, 2023 at 11:36 AM Ion Gaztañaga via Boost <boost(a)lists.boost.org> wrote: > The release notes page seems hard to parse, though: > > https://www.boost.revsys.dev/releases/ Ahem... well, would you believe that me and Greg pulled that one out from scratch from our collective arse just hours before the announcement? In other words, it is a placeholder / design sketch. It will get a proper treatment shortly (and be actually hooked up to the database by the talented Lacey). Thanks

1 0

Re: [boost] charconv for C++11
by Stephan T. Lavavej 11 May '23

11 May '23

[Peter Dimov] > lexical_cast does a good job of optimizing the from_chars and to_chars > cases when it detects it can do so, but that by definition can't be better > than the programmer just calling the primitive operations from_chars > and to_chars directly, as they are (a) locale-independent, (b) non- > allocating, (c) non-throwing. I wondered how lexical_cast's "good job" (limited by the algorithms at the time, not its fault!) compared to charconv, so I dusted off the performance comparison I wrote for CppCon 2019 and added lexical_cast. MSVC's charconv is approximately 14x (for float) and 25x (for double) faster - that's times, not percent. (Thanks to Ryu by Ulf Adams.) This is with avoiding dynamic memory allocation in lexical_cast by converting into a small std::array. My absolute numbers (in a Ryzen 5950X VM): 452.3 ns | Boost float 1003.0 ns | Boost double 32.1 ns | STL float plain shortest 39.9 ns | STL double plain shortest Here's my full test case, built with VS 2022 17.6 Preview 7 x64 (note that x64 vs. x86 makes a HUGE difference to charconv). I didn't bother to compare the from_chars scenario (as MSVC doesn't use a highly optimized algorithm there; investigating Eisel-Lemire is on our todo list). C:\Temp>type charconv.cpp // cl /std:c++17 /EHsc /nologo /W4 /MT /O2 /Iboost_1_82_0 charconv.cpp && charconv #ifndef _MSC_VER #define AVOID_CHARCONV #define AVOID_SPRINTF_S #endif // _MSC_VER #ifndef AVOID_CHARCONV #include <charconv> #endif // AVOID_CHARCONV #include <array> #include <chrono> #include <exception> #include <random> #include <stdint.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <system_error> #include <type_traits> #include <vector> #include <boost/lexical_cast.hpp> using namespace std; using namespace std::chrono; void verify(const bool b) { if (!b) { puts("FAIL"); exit(EXIT_FAILURE); } } enum class RoundTrip { Sci, Fix, Gen, Hex, Lossy }; constexpr size_t N = 2'000'000; // how many floating-point values to test constexpr size_t K = 5; // how many times to repeat the test, for cleaner timing constexpr size_t BufSize = 2'000; // more than enough unsigned int global_dummy = 0; template <typename Floating> void test_lexical_cast(const char* const str, const vector<Floating>& vec) { const auto start = steady_clock::now(); for (size_t k = 0; k < K; ++k) { for (const auto& elem : vec) { const auto ret = boost::lexical_cast<array<char, 25>>(elem); // "-1.2345678901234567e-100" plus null term global_dummy += static_cast<unsigned int>(ret[0]); } } const auto finish = steady_clock::now(); printf("%6.1f ns | %s\n", duration<double, nano>{finish - start}.count() / (N * K), str); } template <typename Floating> int sprintf_wrapper(char (&buf)[BufSize], const char* const fmt, const Floating elem) { #ifdef AVOID_SPRINTF_S return sprintf(buf, fmt, elem); #else // AVOID_SPRINTF_S return sprintf_s(buf, BufSize, fmt, elem); #endif // AVOID_SPRINTF_S } template <RoundTrip RT, typename Floating> void test_sprintf(const char* const str, const vector<Floating>& vec, const char* const fmt) { char buf[BufSize]; const auto start = steady_clock::now(); for (size_t k = 0; k < K; ++k) { for (const auto& elem : vec) { const int ret = sprintf_wrapper(buf, fmt, elem); global_dummy += static_cast<unsigned int>(ret); global_dummy += static_cast<unsigned int>(buf[0]); } } const auto finish = steady_clock::now(); printf("%6.1f ns | %s\n", duration<double, nano>{finish - start}.count() / (N * K), str); for (const auto& elem : vec) { verify(sprintf_wrapper(buf, fmt, elem) != -1); if constexpr (RT == RoundTrip::Lossy) { // skip lossy conversions } else if constexpr (is_same_v<Floating, float>) { verify(strtof(buf, nullptr) == elem); } else { verify(strtod(buf, nullptr) == elem); } } } #ifndef AVOID_CHARCONV constexpr chars_format chars_format_from_RoundTrip(const RoundTrip rt) { switch (rt) { case RoundTrip::Sci: return chars_format::scientific; case RoundTrip::Fix: return chars_format::fixed; case RoundTrip::Gen: return chars_format::general; case RoundTrip::Hex: return chars_format::hex; case RoundTrip::Lossy: default: puts("FAIL"); exit(EXIT_FAILURE); } } template <RoundTrip RT, typename Floating, typename... Args> void test_to_chars(const char* const str, const vector<Floating>& vec, const Args&... args) { char buf[BufSize]; const auto start = steady_clock::now(); for (size_t k = 0; k < K; ++k) { for (const auto& elem : vec) { const auto result = to_chars(buf, buf + BufSize, elem, args...); global_dummy += static_cast<unsigned int>(result.ptr - buf); global_dummy += static_cast<unsigned int>(buf[0]); } } const auto finish = steady_clock::now(); printf("%6.1f ns | %s\n", duration<double, nano>{finish - start}.count() / (N * K), str); for (const auto& elem : vec) { const auto result = to_chars(buf, buf + BufSize, elem, args...); verify(result.ec == errc{}); if constexpr (RT == RoundTrip::Lossy) { // skip lossy conversions } else { Floating round_trip; const auto from_result = from_chars(buf, result.ptr, round_trip, chars_format_from_RoundTrip(RT)); verify(from_result.ec == errc{}); verify(from_result.ptr == result.ptr); verify(round_trip == elem); } } } #endif // AVOID_CHARCONV template <RoundTrip RT, typename Floating> vector<char> prepare_strings(const vector<Floating>& vec) { vector<char> output; char buf[BufSize]; for (const auto& elem : vec) { int ret; if constexpr (RT == RoundTrip::Sci) { if constexpr (is_same_v<Floating, float>) { ret = sprintf_wrapper(buf, "%.8e", elem); } else { ret = sprintf_wrapper(buf, "%.16e", elem); } } else { static_assert(RT == RoundTrip::Hex); if constexpr (is_same_v<Floating, float>) { ret = sprintf_wrapper(buf, "%.6a", elem); } else { ret = sprintf_wrapper(buf, "%.13a", elem); } } verify(ret != -1); output.insert(output.end(), buf, buf + ret + 1); // include null terminator } return output; } template <typename Floating> void test_strtox(const char* const str, const vector<Floating>& original, const vector<char>& strings) { vector<Floating> round_trip(N); const auto start = steady_clock::now(); for (size_t k = 0; k < K; ++k) { const char* ptr = strings.data(); char* endptr = nullptr; for (size_t n = 0; n < N; ++n) { if constexpr (is_same_v<Floating, float>) { round_trip[n] = strtof(ptr, &endptr); } else { round_trip[n] = strtod(ptr, &endptr); } ptr = endptr + 1; // advance past null terminator } } const auto finish = steady_clock::now(); printf("%6.1f ns | %s\n", duration<double, nano>{finish - start}.count() / (N * K), str); verify(round_trip == original); } #ifndef AVOID_CHARCONV vector<char> erase_0x(const vector<char>& strings) { vector<char> output; output.reserve(strings.size() - 2 * N); for (auto i = strings.begin(); i != strings.end();) { if (*i == '-') { output.push_back('-'); i += 3; // advance past "-0x"; } else { i += 2; // advance past "0x"; } for (;;) { const char c = *i++; output.push_back(c); if (c == '\0') { break; } } } return output; } template <RoundTrip RT, typename Floating> void test_from_chars(const char* const str, const vector<Floating>& original, const vector<char>& strings) { const char* const last = strings.data() + strings.size(); vector<Floating> round_trip(N); const auto start = steady_clock::now(); for (size_t k = 0; k < K; ++k) { const char* first = strings.data(); for (size_t n = 0; n < N; ++n) { const auto from_result = from_chars(first, last, round_trip[n], chars_format_from_RoundTrip(RT)); first = from_result.ptr + 1; // advance past null terminator } } const auto finish = steady_clock::now(); printf("%6.1f ns | %s\n", duration<double, nano>{finish - start}.count() / (N * K), str); verify(round_trip == original); } #endif // AVOID_CHARCONV void test_all() { #if defined(__clang__) && defined(_M_IX86) const char* const toolset = "Clang/LLVM x86 + MSVC STL"; #elif defined(__clang__) && defined(_M_X64) const char* const toolset = "Clang/LLVM x64 + MSVC STL"; #elif !defined(__clang__) && defined(_M_IX86) const char* const toolset = "C1XX/C2 x86 + MSVC STL"; #elif !defined(__clang__) && defined(_M_X64) const char* const toolset = "C1XX/C2 x64 + MSVC STL"; #else const char* const toolset = "Unknown Toolset"; #endif puts(toolset); vector<float> vec_flt; vector<double> vec_dbl; { mt19937_64 mt64; vec_flt.reserve(N); while (vec_flt.size() < N) { const uint32_t val = static_cast<uint32_t>(mt64()); constexpr uint32_t inf_nan = 0x7F800000U; if ((val & inf_nan) == inf_nan) { continue; // skip INF/NAN } float flt; static_assert(sizeof(flt) == sizeof(val)); memcpy(&flt, &val, sizeof(flt)); vec_flt.push_back(flt); } vec_dbl.reserve(N); while (vec_dbl.size() < N) { const uint64_t val = mt64(); constexpr uint64_t inf_nan = 0x7FF0000000000000ULL; if ((val & inf_nan) == inf_nan) { continue; // skip INF/NAN } double dbl; static_assert(sizeof(dbl) == sizeof(val)); memcpy(&dbl, &val, sizeof(dbl)); vec_dbl.push_back(dbl); } } test_lexical_cast("Boost float", vec_flt); test_lexical_cast("Boost double", vec_dbl); test_sprintf<RoundTrip::Sci>("CRT float scientific 8", vec_flt, "%.8e"); test_sprintf<RoundTrip::Sci>("CRT double scientific 16", vec_dbl, "%.16e"); test_sprintf<RoundTrip::Lossy>("CRT float fixed 6 (lossy)", vec_flt, "%f"); test_sprintf<RoundTrip::Lossy>("CRT double fixed 6 (lossy)", vec_dbl, "%f"); test_sprintf<RoundTrip::Gen>("CRT float general 9", vec_flt, "%.9g"); test_sprintf<RoundTrip::Gen>("CRT double general 17", vec_dbl, "%.17g"); test_sprintf<RoundTrip::Hex>("CRT float hex 6", vec_flt, "%.6a"); test_sprintf<RoundTrip::Hex>("CRT double hex 13", vec_dbl, "%.13a"); #ifndef AVOID_CHARCONV test_to_chars<RoundTrip::Gen>("STL float plain shortest", vec_flt); test_to_chars<RoundTrip::Gen>("STL double plain shortest", vec_dbl); test_to_chars<RoundTrip::Sci>("STL float scientific shortest", vec_flt, chars_format::scientific); test_to_chars<RoundTrip::Sci>("STL double scientific shortest", vec_dbl, chars_format::scientific); test_to_chars<RoundTrip::Fix>("STL float fixed shortest", vec_flt, chars_format::fixed); test_to_chars<RoundTrip::Fix>("STL double fixed shortest", vec_dbl, chars_format::fixed); test_to_chars<RoundTrip::Gen>("STL float general shortest", vec_flt, chars_format::general); test_to_chars<RoundTrip::Gen>("STL double general shortest", vec_dbl, chars_format::general); test_to_chars<RoundTrip::Hex>("STL float hex shortest", vec_flt, chars_format::hex); test_to_chars<RoundTrip::Hex>("STL double hex shortest", vec_dbl, chars_format::hex); test_to_chars<RoundTrip::Sci>("STL float scientific 8", vec_flt, chars_format::scientific, 8); test_to_chars<RoundTrip::Sci>("STL double scientific 16", vec_dbl, chars_format::scientific, 16); test_to_chars<RoundTrip::Lossy>("STL float fixed 6 (lossy)", vec_flt, chars_format::fixed, 6); test_to_chars<RoundTrip::Lossy>("STL double fixed 6 (lossy)", vec_dbl, chars_format::fixed, 6); test_to_chars<RoundTrip::Gen>("STL float general 9", vec_flt, chars_format::general, 9); test_to_chars<RoundTrip::Gen>("STL double general 17", vec_dbl, chars_format::general, 17); test_to_chars<RoundTrip::Hex>("STL float hex 6", vec_flt, chars_format::hex, 6); test_to_chars<RoundTrip::Hex>("STL double hex 13", vec_dbl, chars_format::hex, 13); #endif // AVOID_CHARCONV puts("----------"); const vector<char> strings_sci_flt = prepare_strings<RoundTrip::Sci>(vec_flt); const vector<char> strings_sci_dbl = prepare_strings<RoundTrip::Sci>(vec_dbl); const vector<char> strings_hex_flt = prepare_strings<RoundTrip::Hex>(vec_flt); const vector<char> strings_hex_dbl = prepare_strings<RoundTrip::Hex>(vec_dbl); test_strtox("CRT strtof float scientific", vec_flt, strings_sci_flt); test_strtox("CRT strtod double scientific", vec_dbl, strings_sci_dbl); test_strtox("CRT strtof float hex", vec_flt, strings_hex_flt); test_strtox("CRT strtod double hex", vec_dbl, strings_hex_dbl); #ifndef AVOID_CHARCONV test_from_chars<RoundTrip::Sci>("STL from_chars float scientific", vec_flt, strings_sci_flt); test_from_chars<RoundTrip::Sci>("STL from_chars double scientific", vec_dbl, strings_sci_dbl); test_from_chars<RoundTrip::Hex>("STL from_chars float hex", vec_flt, erase_0x(strings_hex_flt)); test_from_chars<RoundTrip::Hex>("STL from_chars double hex", vec_dbl, erase_0x(strings_hex_dbl)); #endif // AVOID_CHARCONV printf("global_dummy: %u\n", global_dummy); } int main() { try { test_all(); } catch (const exception& e) { printf("Exception: %s\n", e.what()); } catch (...) { printf("Unknown exception.\n"); } } C:\Temp>cl /std:c++17 /EHsc /nologo /W4 /MT /O2 /Iboost_1_82_0 charconv.cpp && charconv charconv.cpp C1XX/C2 x64 + MSVC STL 452.3 ns | Boost float 1003.0 ns | Boost double 222.7 ns | CRT float scientific 8 381.3 ns | CRT double scientific 16 231.3 ns | CRT float fixed 6 (lossy) 818.3 ns | CRT double fixed 6 (lossy) 260.1 ns | CRT float general 9 807.6 ns | CRT double general 17 96.0 ns | CRT float hex 6 117.4 ns | CRT double hex 13 32.1 ns | STL float plain shortest 39.9 ns | STL double plain shortest 31.2 ns | STL float scientific shortest 39.7 ns | STL double scientific shortest 37.6 ns | STL float fixed shortest 111.7 ns | STL double fixed shortest 31.8 ns | STL float general shortest 39.9 ns | STL double general shortest 14.9 ns | STL float hex shortest 18.3 ns | STL double hex shortest 48.9 ns | STL float scientific 8 57.4 ns | STL double scientific 16 35.2 ns | STL float fixed 6 (lossy) 93.2 ns | STL double fixed 6 (lossy) 59.4 ns | STL float general 9 70.4 ns | STL double general 17 16.2 ns | STL float hex 6 19.1 ns | STL double hex 13 ---------- 103.7 ns | CRT strtof float scientific 191.2 ns | CRT strtod double scientific 56.6 ns | CRT strtof float hex 86.0 ns | CRT strtod double hex 77.2 ns | STL from_chars float scientific 154.3 ns | STL from_chars double scientific 26.2 ns | STL from_chars float hex 30.1 ns | STL from_chars double hex global_dummy: 3715056096 Hope this helps, STL

1 0

Re: [boost] New Website !
by Ion Gaztañaga 11 May '23

11 May '23

On 11/05/2023 19:35, Glen Fernandes via Boost wrote: > On Thu, May 11, 2023 at 10:35 AM Vinnie Falco wrote: > >> Hey, it’s Vinnie here again! I have some very exciting news to share >> with you. The renovated website for Boost that we’ve been working on >> for far too long is now going into its Public Beta phase! Feel free to >> poke around and kick the tires but keep in mind this is a piece of >> software and it is still under development. Some parts are missing, >> incomplete,or buggy. Without further ado: >> >> https://boost.revsys.dev > > Thank you for working on this. The mechanics of this site are already > impressive, and the dark mode design looks very nice (the Boost logo, > theme, and all) even in its beta form. New documentation for Boost users > about building and installing Boost, and for potential Boost authors about > contributing to Boost development is also great to see. > > If anyone else viewing this like me has their system detected by the site > as "light themed", then view the site in the dark mode. It has a much > better look, and apparently the light mode design is still in progress. > > When the site is more developed, I can make sure that the release > information also gets published to the new site. > > Glen I also would like to thank everyone pushing the new website, Boost needs a more modern one. The release notes page seems hard to parse, though: https://www.boost.revsys.dev/releases/ Maybe a bit of separation between libraries (and marking libraries with some bold or underlinining) can help a bit. Or if the library changes list is a bit long, a TOC section could also help. Best, Ion

1 0

Re: [boost] charconv for C++11
by Peter Dimov 11 May '23

11 May '23

Robert Ramey wrote: > We convert character arrays into built-in arithmetic types and vice versa. > That’s it. > > I believe that this is what lexical_cast does. It might be different in that other > than using arrays it uses strings. lexical_cast can convert any streamable type to any other streamable type. It's defined as `ss << input; ss >> output; return output;` where `ss` is a default-constructed `std::stringstream`. This has a number of implications. One, the conversion is locale-dependent. Two, for conversion to string, you use lexical_cast<std::string>, which can allocate. Three, errors are signaled via exceptions (although there's try_lexical_convert that can avoid this.) lexical_cast does a good job of optimizing the from_chars and to_chars cases when it detects it can do so, but that by definition can't be better than the programmer just calling the primitive operations from_chars and to_chars directly, as they are (a) locale-independent, (b) non- allocating, (c) non-throwing. In addition to all that, from/to_chars are standard C++17, so Charconv can be used by libraries that want to support C++11 (or 14) today, but at the same time want to be able to switch to the standard functions later when increasing the minimal supported standard to C++17.

1 0

Re: [boost] charconv for C++11
by Andrzej Krzemienski 11 May '23

11 May '23

On Wed, May 10, 2023, 19:42 Peter Dimov via Boost <boost(a)lists.boost.org> wrote: > Matt Borland wrote: > > > On May 10, 2023, at 5:42 PM, Dominique Devienne > > <ddevienne(a)gmail.com> wrote: > > > > > > On Wed, May 10, 2023 at 4:01 PM Matt Borland via Boost > > <boost(a)lists.boost.org> wrote: > > > > > >> [...] We use errno rather than std::error_code as specified in the > standard. > > > > > > Hi. Sounded like a good candidate for Boost.Compat (or > > > Boost.Polyfill), discussed recently, until that sentence. I'm lucky > > > enough to be able to use > > > C++17 at work, but if I was on C++11, I'd tend to use such a library > > > C++until > > > I could use the std one, so deviations like this would complicate > > > adoption because moving to std would then be harder. My $0.02. —DD > > > > Dominique, > > > > Thanks for the response. We discussed Boost.Compat but decided it is > outside > > of the scope. For instance <latch> is what set off the discussion and it > can be > > implemented in ~100 LOC. This implementation of charconv will be around > > 10k LOC so it should be in its own library. If the demand signal is to > use > > std::error_code instead of errno we can make the change. > > boost/charconv.hpp was initially supposed to be a very light header (with > only > a few declarations), but since from/to_chars for integral types were moved > to the headers because of constexpr, What is the connection between constexpr and moving things to headers? Regards, &rzej; that's no longer the case, so we can > probably afford the inclusion of <system_error> without anyone noticing. > > (Note that std::from/to_chars use std::errc, not std::error_code.) > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

Extra file in boost serialization for 1.82.0
by Bryan St. Amour 11 May '23

11 May '23

Hi, I noticed that under boost/serialization, there is a file "collection_size_type copy.hpp" (notice the space in the file name.) Comparing it with the contents of collection_size_type.hpp, it looks like "collection_size_type copy.hpp" is newer. Can someone verify which one is the correct collection_size_type header file? Thanks, Bryan

1 0

Re: [boost] New Website !
by Glen Fernandes 11 May '23

11 May '23

On Thu, May 11, 2023 at 10:35 AM Vinnie Falco wrote: > Hey, it’s Vinnie here again! I have some very exciting news to share > with you. The renovated website for Boost that we’ve been working on > for far too long is now going into its Public Beta phase! Feel free to > poke around and kick the tires but keep in mind this is a piece of > software and it is still under development. Some parts are missing, > incomplete,or buggy. Without further ado: > > https://boost.revsys.dev Thank you for working on this. The mechanics of this site are already impressive, and the dark mode design looks very nice (the Boost logo, theme, and all) even in its beta form. New documentation for Boost users about building and installing Boost, and for potential Boost authors about contributing to Boost development is also great to see. If anyone else viewing this like me has their system detected by the site as "light themed", then view the site in the dark mode. It has a much better look, and apparently the light mode design is still in progress. When the site is more developed, I can make sure that the release information also gets published to the new site. Glen

1 0

Re: [boost] charconv for C++11
by Robert Ramey 11 May '23

11 May '23

On 5/11/23 7:40 AM, Matt Borland via Boost wrote: >> How is this different from boost lexical cast? > > Robert, > > Charconv has a much smaller scope than lexical cast. We convert character arrays into built-in arithmetic types and vice versa. That’s it. I believe that this is what lexical_cast does. It might be different in that other than using arrays it uses strings. Since it has such a narrow scope we can heavily optimize these conversions, Honestly, I don't see how the scope is that much narrower than lexical_cast. which we have sunk a lot of time and effort into. I presume you're referring to charconv and not lexical_cast here. I don't question anyone's commitment, motives or competence in their efforts to contributing to boost. But this is not in itself an argument for accepting or rejecting a boost library submission. Thinking ahead a little bit, I'd have the following questions which might be brought up were such a component come up for review. a) How is this different from boost lexical cast? https://theboostcpplibraries.com/boost.lexical_cast. b) What will be the difference in user experience? c) if it's very similar, why wouldn't it be better to just enhance/refine/improve/correct lexical_cast itself? d) lexical cast uses an implementation strategy of leveraging C++ standard io library. This is a header only library which presumably, results in code highly optimized at compile time. Also it doesn't add any dependencies other than the standard library itself. Of course this optimization and hence performance will vary from one standard library/compiler implementation to another. But the same question applies to code written from scratch. Robert Ramey > > Matt > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] charconv for C++11
by Matt Borland 11 May '23

11 May '23

On Thu, May 11, 2023 at 17:16, Andrey Semashev via Boost <[boost@lists.boost.org](mailto:On Thu, May 11, 2023 at 17:16, Andrey Semashev via Boost <<a href=)> wrote: > On 5/11/23 17:40, Matt Borland via Boost wrote: >>> How is this different from boost lexical cast? >> >> Robert, >> >> Charconv has a much smaller scope than lexical cast. We convert character arrays into built-in arithmetic types and vice versa. That’s it. Since it has such a narrow scope we can heavily optimize these conversions, which we have sunk a lot of time and effort into. > > I remember there were a lot of optimizations poured into > Boost.Spirit.Qi/Karma. How does your library compare to those > implementations? > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Andrey, Frankly I’ve never looked at Boost.Spirit before. I can add comparison benchmarks to the charconv docs. Matt

1 0

Re: [boost] charconv for C++11
by Andrey Semashev 11 May '23

11 May '23

On 5/11/23 17:21, Vinnie Falco via Boost wrote: > On Thu, May 11, 2023 at 6:50 AM Robert Ramey via Boost > <boost(a)lists.boost.org> wrote: >> How is this different from boost lexical cast? > > Oh wow this has got to be one of the most amusing things posted to the > mailing list this year with the exception of the mathematical > breakthrough post which attached a gif of the author's monitor showing > the source code instead of providing a github link. I see nothing funny about Robert's post. Asking for comparison with existing solutions is a very reasonable request.

1 0

Re: [boost] charconv for C++11
by Andrey Semashev 11 May '23

11 May '23

On 5/11/23 17:40, Matt Borland via Boost wrote: >> How is this different from boost lexical cast? > > Robert, > > Charconv has a much smaller scope than lexical cast. We convert character arrays into built-in arithmetic types and vice versa. That’s it. Since it has such a narrow scope we can heavily optimize these conversions, which we have sunk a lot of time and effort into. I remember there were a lot of optimizations poured into Boost.Spirit.Qi/Karma. How does your library compare to those implementations?

1 0

Re: [boost] charconv for C++11
by Matt Borland 11 May '23

11 May '23

> How is this different from boost lexical cast? Robert, Charconv has a much smaller scope than lexical cast. We convert character arrays into built-in arithmetic types and vice versa. That’s it. Since it has such a narrow scope we can heavily optimize these conversions, which we have sunk a lot of time and effort into. Matt

1 0

New Website !
by Vinnie Falco 11 May '23

11 May '23

Hey, it’s Vinnie here again! I have some very exciting news to share with you. The renovated website for Boost that we’ve been working on for far too long is now going into its Public Beta phase! Feel free to poke around and kick the tires but keep in mind this is a piece of software and it is still under development. Some parts are missing, incomplete,or buggy. Without further ado: https://boost.revsys.dev This public beta will extend for at least 10 weeks as we finish the last remaining features, and put a few more rounds of polish on the artwork, visual styling, and user interface. After that if you like what you see then we will reset the database, move the repositories and the site to their new homes, and then deploy it for real! If you have suggestions or wish to report problems please feel welcome to open an issue here: https://github.com/cppalliance/temp-site/issues This is a Django site written and maintained in Python by a great group of folks from https://www.revsys.com/. The project is coordinated by Frank Wiles (https://www.revsys.com/about/bio/frankwiles) who shares the same deep commitment to open source that we Boost people do. We chose Django because it is well understood and supported, and because Python composes well with ease of maintenance. This technology stack allows us to execute on our future plans with confidence. Some cool things about this website include: * Log in with GitHub or Google * Light and Dark themes with selector * Asciidoc markdown for dynamic content * Antora content sources for site documentation * Data-driven dynamic pages for libraries and releases * Integrated control panel for producing Boost releases * Full-text search across the documentation and library headers * Professionally designed logo to evoke identity and instant recognition The layout of the site is carefully thought out to make sure that information can be found quickly. Fundamental topics each get a dedicated word in the top level navigation, visible on every page including the site and library documentation. Most of the information which is not library-specific is warehoused in “site docs” which is a collection of individual Antora content sources each authored in Asciidoc. Anyone can update the information on the website simply by contributing to the site-docs via pull request: https://github.com/cppalliance/site-docs Antora and Asciidoc are potent technologies that offer Boost plenty of room to grow to make our site documentation and library documentation more effective for users. While the initial release of the website after the beta will only have the basic functionality, we have many future plans. Some of these you have heard about already and some are new: * A web-based forum which interacts seamlessly with the mailing list * Polls and surveys for measuring the sentiment of Boost users and stakeholders * News section for aggregating off-site links, blog posts, and release progress messages * Integrated Review process. Outcomes go in the database and become dynamic content. * User Profiles record and show activity such as review participation or library submission We’re all very excited and proud of the work that went into this thing and hope that it really fulfills the positive impact that we intended. Thanks! Vinnie

1 0

Re: [boost] charconv for C++11
by Vinnie Falco 11 May '23

11 May '23

On Thu, May 11, 2023 at 6:50 AM Robert Ramey via Boost <boost(a)lists.boost.org> wrote: > How is this different from boost lexical cast? Oh wow this has got to be one of the most amusing things posted to the mailing list this year with the exception of the mathematical breakthrough post which attached a gif of the author's monitor showing the source code instead of providing a github link. Thanks

1 0

Re: [boost] charconv for C++11
by Robert Ramey 11 May '23

11 May '23

On 5/10/23 4:08 PM, Gavin Lambert via Boost wrote: > On 11/05/2023 02:01, Matt Borland wrote: >> What does charconv do? It converts a character sequence into a number >> (from_chars) or converts a number into a character sequence >> (to_chars). How is this different from boost lexical cast? Robert Ramey

1 0

Re: [boost] charconv for C++11
by Gavin Lambert 10 May '23

10 May '23

On 11/05/2023 02:01, Matt Borland wrote: > What does charconv do? It converts a character sequence into a number > (from_chars) or converts a number into a character sequence > (to_chars). This is similar to strtod and printf with a few key > differences. First and most important is a roundtrip guarantee. That > is a number converted into a character sequence, and then back into a > number will be identical to the starting value. Second, you can > easily specify an input/output format with a chars_format argument, > and also provide a target precision. "Roundtrip guarantee" and "specify format/precision" appear to be contradictory goals.

1 0

Re: [boost] charconv for C++11
by Peter Dimov 10 May '23

10 May '23

Matt Borland wrote: > > On May 10, 2023, at 5:42 PM, Dominique Devienne > <ddevienne(a)gmail.com> wrote: > > > > On Wed, May 10, 2023 at 4:01 PM Matt Borland via Boost > <boost(a)lists.boost.org> wrote: > > > >> [...] We use errno rather than std::error_code as specified in the standard. > > > > Hi. Sounded like a good candidate for Boost.Compat (or > > Boost.Polyfill), discussed recently, until that sentence. I'm lucky > > enough to be able to use > > C++17 at work, but if I was on C++11, I'd tend to use such a library > > C++until > > I could use the std one, so deviations like this would complicate > > adoption because moving to std would then be harder. My $0.02. —DD > > Dominique, > > Thanks for the response. We discussed Boost.Compat but decided it is outside > of the scope. For instance <latch> is what set off the discussion and it can be > implemented in ~100 LOC. This implementation of charconv will be around > 10k LOC so it should be in its own library. If the demand signal is to use > std::error_code instead of errno we can make the change. boost/charconv.hpp was initially supposed to be a very light header (with only a few declarations), but since from/to_chars for integral types were moved to the headers because of constexpr, that's no longer the case, so we can probably afford the inclusion of <system_error> without anyone noticing. (Note that std::from/to_chars use std::errc, not std::error_code.)

1 0

Re: [boost] charconv for C++11
by Dominique Devienne 10 May '23

10 May '23

On Wed, May 10, 2023 at 4:01 PM Matt Borland via Boost < boost(a)lists.boost.org> wrote: > [...] We use errno rather than std::error_code as specified in the > standard. Hi. Sounded like a good candidate for Boost.Compat (or Boost.Polyfill), discussed recently, until that sentence. I'm lucky enough to be able to use C++17 at work, but if I was on C++11, I'd tend to use such a library until I could use the std one, so deviations like this would complicate adoption because moving to std would then be harder. My $0.02. --DD

2 1

charconv for C++11
by Matt Borland 10 May '23

10 May '23

I’m Matt Borland, who many might recognize from my work in Boost.Math and fewer might know from Boost.Multiprecision. I’m putting the finishing touches on a new library that I hope will become part of Boost, after a successful formal review. This library is essentially already part of C++17 and later but in the Boost tradition we wish to provide it for users and other Boost libraries that want to fully support C++14 or C++11. What does charconv do? It converts a character sequence into a number (from_chars) or converts a number into a character sequence (to_chars). This is similar to strtod and printf with a few key differences. First and most important is a roundtrip guarantee. That is a number converted into a character sequence, and then back into a number will be identical to the starting value. Second, you can easily specify an input/output format with a chars_format argument, and also provide a target precision. Third, it is much easier to check for errors. Strtod has a few different ways of reporting different errors whereas the results of to_chars returns an error code from errno. Using this is no different from POSIX where you check for 0 and then move on. We use errno rather than std::error_code as specified in the standard. This allows us to avoid including <system_error> and is more ergonomic. Lastly, charconv is significantly more performant than strtod and printf. We utilize algorithms derived from Daniel Lemire’s “Number Parsing at a Gigabyte per Second” and Junkey Jeon’s Dragonbox. You can read about those here: https://arxiv.org/abs/2101.11408 https://github.com/jk-jeon/dragonbox And here are a number of example snippets: https://develop.charconv.cpp.al/ As of now the library supports all built-in integer types, signed and unsigned __int128, float, and double. I am striving to add support for long doubles (64, 80, and 128-bit) to both from_chars and to_chars. With these in hand I have a mind to experiment with integrating this into Boost.JSON, which for lack of a better phrase, sure could use a bit of help with its conversions between IEEE floats and decimal strings. This will also help with checking our validation, accuracy, and performance. If you want to check out the library it is here: [https://github.com/cppalliance/charconv](https://github.com/CPPAlliance/cha… It is designed to be built and used in the Boost superproject. This means that if you want to clone it, you should place the repository in the libs/charconv directory of your local superproject. Feel free to hammer on it, and report any errors or performance issues that you run into. Also if you find the docs could use improvement please open an issue so that we can address it. These will help us ensure that we have the highest quality product before attempting to pass a formal review for inclusion in Boost. Thank you for your time. Matt Borland

1 0

Re: [boost] Full-Text Boost Search
by Vinnie Falco 10 May '23

10 May '23

On Wed, May 10, 2023 at 1:46 AM Antony Polukhin via Boost <boost(a)lists.boost.org> wrote: > Adding support of it to Doxygen should do the job of implementing both > searches and helping the C++ community in general. To add some context to what Mohammad is saying, I've been using Doxygen for years as part of my "docca" toolchain for building C++ library reference pages. For example: https://www.boost.org/doc/libs/1_82_0/libs/json/doc/html/json/ref/boost__js… I've reached the limit of what Doxygen is capable of and now it is blocking the improvement of documentation. Doxygen's XML output is always behind the HTML output, and there is no really good Asciidoc output. Furthermore Doxygen uses outdated technology for analyzing the C++ program. That is why I have created a new program called "Mr. Dox." This program uses clang's unstable libtooling API to generate an AST tree of a library's actual translation units (the .cpp files) and not just looking at headers using fancy regex or the simplified libclang API. Some discussion on that: https://www.foonathan.net/2019/11/standardese-post-mortem/ Because MrDox uses the exact same API that clang uses to actually compile your program, it can understand every C++ construct. If clang can compile it, then MrDox can see it. That means we can see deduction guides, alias templates, class template specializations, and much much more. The capability of extracting C++ source code features with perfect fidelity allows us to build features which enhance the generated reference in ways that Doxygen never can. For example we can recurse deeply into the AST and analyze the expression inside a conditional noexcept specification. We can understand abbreviated function template parameters. In fact, MrDox can eventually understand C++ features which are not yet part of the Standard but merged into the trunk of LLVM because they are supported by Technical Specifications ("TS") approved by the C++ Standardization Committee. This means MrDox can always stay current and keep pace with every innovation that comes to C++. The program is still in development but we are targeting the winter release date of Boost for having an packaged executable that is ready for production, with a good Asciidoc generator. Check it out here: https://github.com/cppalliance/mrdox Thanks! Vinnie

1 0

Re: [boost] Web documentation question
by Marshall Clow 10 May '23

10 May '23

> On May 10, 2023, at 2:43 AM, Alain O' Miniussi via Boost <boost(a)lists.boost.org> wrote: > > Hi, > > I sometime need to contribute to boost but it is clearly not a regular activity. > And each time it takes me an unreasonable amount of time just to find the relevant git clone command. > > I would like to know if something is inherently wrong with: > 1) go to www.boost.org > 2) unfold the "Development" menu on the right > 3) hope to find the information regarding the development cycle > > right now, these sections mostly contains pages with link the the wiki, which is expected to be at svn.boost.org which cannot be reached. > > If the information is actually at https://github.com/boostorg/wiki/wiki/Getting-Started%3A-Overview (thanks you stackoverflow) why isn't that page referenced from https://www.boost.org/development/index.html or https://github.com/boostorg/boost ? Thank you for bringing this to my (our?) attention. I am currently attending C++Now, and have no time to deal with this this week, but I have created https://github.com/boostorg/website/issues/754 <https://github.com/boostorg/website/issues/754> to track this so it will not be lost. — Marshall

1 0