- Boost - lists.preview.boost.org

Review of Parser library begins today
by Marshall Clow 19 Feb '24

19 Feb '24

The review of Zach Laine’s proposed Boost.Parser library begins today and will end on February 28th. From the introduction page of the documentation: 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(). Github: https://github.com/tzlaine/parser Docs https://tzlaine.github.io/parser — Marshall

1 0

Re: [boost] Should boost::core::string_view be made public?
by g.peterhoff＠t-online.de 18 Feb '24

18 Feb '24

Have you come to a conclusion how this should be handled (in the future)? The problem is basically that there are different implementations for string_view. I don't know why it was done this way. Presumably it's because various boost libraries want to be independent of others, so that some things are implemented anew each time (within the library) instead of using existing libraries. This will also be due to the fact that boost is not atomistic enough, so that large libraries might have to be included/used, although only a fraction of the functionality is needed. My suggestion: - Throw out boost::utility::string_view - Make boost::core::detail::string_view public, just like all other backports in boost::core. - Check if there are other multiple implementations. If so, pull them out into separate small boost libraries. (For databases, this would be called normalization, but it must not be over-normalized). regards Gero

5 4

Potential Launch of Boost Website: Request for Final Feedback
by Louis Tatta 17 Feb '24

17 Feb '24

Louis here from the C++ Alliance. With the potential launch of the new Boost website on the horizon this week, we're making a final call for your feedback. Your insights a few months ago were incredibly helpful, and as we approach the launch, we'd value your final review. If you have a moment to look over the site again and note any issues or suggestions, it would be of great help. Feedback can be submitted on our GitHub issues page: https://github.com/cppalliance/temp-site/issues. Thank you for your ongoing support and contributions to the Boost community. Looking forward to your feedback. Best regards, Louis C++ Alliance

18 79

Re: [boost] New Website Repositories
by Glen Fernandes 16 Feb '24

16 Feb '24

On 2024-02-16, Vinnie Falco wrote: > On Fri, Feb 16, 2024 at 12:33, Glen Fernandes wrote: > > If you want to follow the tradition of source files, the easiest > > convention to follow is to state that your files, e.g. > > > >  > > We can do that, or alternatively is it possible to just plop a LICENSE > file at the root of the repository? I would prefer both (thanks). Glen

1 0

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