- Boost - lists.preview.boost.org

Reminder: Boost 1.85.0 will be closing for new libraries and breaking changes THIS WEDNESDAY
by Marshall Clow 20 Feb '24

20 Feb '24

As always, look at the calendar at https://www.boost.org/development/ — Marshall

2 1

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