March 2021 - Boost - lists.boost.org

Boost accepted in Google Summer of Code 2021
by David Bellot 10 Mar '21

10 Mar '21

We're in again! https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code%3A-2021 David

2 1

[Boost] [Describe] Review Reminder
by Richard Hodges 10 Mar '21

10 Mar '21

A friendly reminder that the review period for [Boost.Describe] is half way through. We've had some excellent feedback already, and would value more. If you can spare a few hours of your valuable time, please consider reviewing this neat little library and posing your results on this mailing list. The invitation is repeated below: The Boost formal review of the Describe starts Monday, taking place from March 1st, 2021 to March 10th, 2021 (inclusive). The library is authored by Peter Dimov. Documentation: https://pdimov.github.io/describe/doc/html/describe.html Source: https://github.com/pdimov/describe The library provides a simple means of providing reflection for structures and enums in C++. The documentation contains a number of common motivating examples, including: - A universal print function https://pdimov.github.io/describe/doc/html/describe.html#example_print_func… - JSON serialisation https://pdimov.github.io/describe/doc/html/describe.html#example_to_json Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including Describe as a Boost library. Please be explicit about your decision (ACCEPT or REJECT). Some other questions you might want to consider answering: - 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 which compiler(s)? 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? More information about the Boost Formal Review Process can be found at: http://www.boost.org/community/reviews.html The review is open to anyone who is prepared to put in the work of evaluating and reviewing the library. Prior experience in contributing to Boost reviews is not a requirement. Thank you for your efforts in the Boost community. They are very much appreciated. Richard Hodges - review manager of the proposed Boost.Describe library Peter is often available in the CppLang Slack #boost channel should you require any clarification not covered by the documentation, as am I. -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 home: +376841522 mobile: +376380212

6 5

[Describe] Review - Part 1: Enumerators
by Andrzej Krzemienski 10 Mar '21

10 Mar '21

Hi Everyone, This is part one of my review of Boost.Describe. I will focus only on dealing with enumerators. Working with C++ enumerations is harder than one might think, because they are not what many people believe. They are just a bunch of integral constants and an integral type. We can get things like this: enum Season { Spring = 1, Summer, Autumn, // British Fall = Autumn, // American Winter, }; struct Human { std::string name; Season born; }; int main() { Human h {}; inspect(h); } void inspect(Human h) { switch(h) { case Spring: case Summer: case Fall: case Winter: return; default: assert(false) } } I can trigger an assertion failure without even doing any cast, because enums can assume other values that those listed in the declaration. The low-level interface provided by Boost.Describe is able to manage all these aspects very nicely. If we call BOOST_DESCRIBE_ENUM on struct Season above, we will get a list of five elements and the user will have to decide what she wants to do with it. On the other hand, requesting that Boost.Describe should provide a higher level enum-to-string mapping seems to overlook the special rules of C++ enums. How do you want this function to behave if the input enum value is not found? What do you want the function to do if it finds more than one corresponding string? The interface of describe_enumerators<> is optimal. Macro BOOST_DESCRIBE_ENUM is redundant: BOOST_DESCRIBE_ENUM_CLASS can handle unscoped enumerations pretty well. Note that in C++11 you can use the qualified names of unscoped enumerators, like Season::Winter in the above example. After playing first with macros for describing structs, I was surprised that the syntax for describing enumerators doesn't use parentheses for the list of enumerators: BOOST_DESCRIBE_ENUM(X, (A, B, C)); // I somehow expected that to work. Describing enums from the global namespace introduces names starting with underscore (_enum_descriptor_fn) into global namespace. This is Undefined Behavior, and is likely to trigger some code sanitizers. Instead use an ugly name, like boost_describe_enum_descriptor_fn. I do not appreciate the BOOST_DEFINE_ macros for enumerations. We get as much as four of them, and neither is able to handle the use case that I consider basic, which I often have in my code: where I omit value zero and start from 1: struct Error { badSoething = 1, badSomethingElse, tooLongSomethng, ... }; So, I am not sure how many real life enums these macros cover. Regards, &rzej;

3 4

[release] Reminder: Master branch closing WEDNESDAY 3/10 for 1.76.0 beta release
by Marshall Clow 10 Mar '21

10 Mar '21

Calendar here: https://www.boost.org/development/ <https://www.boost.org/development/> — Marshall

2 1

Boost beast HTTP server
by Jupiter 09 Mar '21

09 Mar '21

Hi, I installed almost all boost libraries to a Ubuntu 18.04 machine to run services, but I could not find which Ubuntu boost package includes beast, I looked at Internet comments that the cmake seems only working for Windows, how can I build beast in Ubuntu if the beast is not available in any ubuntu boost packages? Also, appreciate links to download breast samples. Thank you very much. Kind regards, Jupiter

2 1

Re: [boost] [Boost] [Describe] library submission - last call for reviews from the community
by Samuel DEBIONNE 09 Mar '21

09 Mar '21

> Please provide in your review information you think is valuable to > understand your choice to ACCEPT or REJECT including Describe as a > Boost library. Please be explicit about your decision (ACCEPT or REJECT). ACCEPT! Thank you Peter for submitting this library. > Some other questions you might want to consider answering: > - What is your evaluation of the implementation? TBH, I did not look at the code much, I expect a lot of preprocessor machinery to generate the metadata. > - What is your evaluation of the documentation? Clean and to the point. Maybe the section "Describing Class Types" could be split in "Describing Class Types" and "Reflecting Class Types" (usage of the description)? Nitpick: the code snippets are missing syntax highlighting. > - What is your evaluation of the potential usefulness of the library? Definitely useful. I see a bright future for this library especially if it makes it to the standard. I am not sure how compatible it is with the C++ Reflection TS though. Baby steps is probably the right approach for such a complex feature... > - Did you try to use the library? With which compiler(s)? Did you > have any problems? GCC 9.3 on Linux. I am not sure if the examples are integrated to the build system yet but compiling them was a no-brainer. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? About two hours, playing with the examples and writing my owns. Like many previous reviewers, I got tricked with the modifiers of the class describer. The | operator might be a bit misleading because some modifiers (mod_function) actually reduce the scope of the description. Reflecting the name of the type would be a nice addition. I am not a big fan of the BOOST_DEFINE_*** macros -actually shouldn't they be BOOST_DESCRIBE_DEFINE_ENUM? But since we have definition macros for enums, for symmetry, how about definition macros for structures -Hana has BOOST_HANA_DEFINE_STRUCT? I wonder if "fixed enum" is a standard terminology? > - Are you knowledgeable about the problem domain? Just from a user perspective. I use Boost.Hana[1] to get some level of reflection on structures. This solution is more limited than the one proposed in Boost.Describe (e.g. does not support member functions out of the box). The scope of Boost.Hana is much larger though and reflection is more a side effect of the Struct concept than a goal of the library. I use Better Enums[2] to get reflection on enums. Magic Enum C++[3] is a more modern alternative. Both libraries offer more features out of the box (aka enum_to_string) but I understand that the purpose of Describe is to "establish a standard way of providing these reflection abilities" and the interface needs to remain minimal to be the common factor. I have a patched Boost.Serialization that supports generic serialization of Hana Struct, just to say that it's possible. Thanks, Samuel 1. https://www.boost.org/doc/libs/1_61_0/libs/hana/doc/html/group__group-Struc… 2. https://github.com/aantron/better-enums 3. https://github.com/Neargye/magic_enum

2 1

[concept_check] Fix issue #31 for Boost 1.76?
by Mateusz Loskot 09 Mar '21

09 Mar '21

Hi. Since VS 2019 16.9.0 is out and rolling, can we put a priority on fixing this issue? https://github.com/boostorg/concept_check/issues/31 IOW, could the maintainers decide which of the discussed fixes they prefer and what PR has chance to be merged promptly for Boost 1.76? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

New home for B2.
by René Ferdinand Rivera Morell 08 Mar '21

08 Mar '21

As some of you may have noticed, B2 has a new home outside the Boost organization at <https://www.bfgroup.xyz/b2/>. The goal of the move is to elevate B2 development above the constraints of the Boost structure. I.e. to make B2 not just the build system that Boost uses. The biggest change to make happen is that last week the B2 fork at < https://github.com/bfgroup/b2> became the base git repo of all existing B2 git repos. And hence it means that the git repo < https://github.com/boostorg/build> is now a fork. What does this mean going forward? This that will not change: * Boost will still get the build system from the same git repo as it does now. * The B2 documentation will still be included in the Boost releases. What will change (eventually), or has already changed: * Development has moved to the new B2 git repo. And hence PRs for B2 will need to be posted to the new repo. * The B2 mail list at < https://lists.boost.org/mailman/listinfo.cgi/boost-build> will be replaced by the GitHub discussion forums at < https://github.com/bfgroup/b2/discussions>. * The B2 version in Boost will be updated from the base git repo for releases of the B2 base only. I.e. a B2 release will get merged to the Boost develop branch. And from there to the master branch. * The Boost testing of B2 reported at < https://www.boost.org/development/tests/develop/developer/summary.html> will stop showing (and hence running) B2 tests.The testing has already moved to cloud CI. And expanded to cover more platforms than Boost usually tests. * The B2 web site at <https://boostorg.github.io/build/> will go away. * The issues at <https://github.com/boostorg/build/issues> will eventually go away (once I deal with enough of them). -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

2 2

[Describe] Clarification on the library scope
by Andrzej Krzemienski 08 Mar '21

08 Mar '21

Hi Everyone, First of all, I wanted to thank Peter for writing and sharing this library. A number of people already indicated it is useful, and I also have use cases that would be addressed by this library. I would lie to clarify if my understanding of the scope of this library is correct. From the discussion so far, I understood that the goal is to provide a low-level minimum building block that enables writing more elaborate libraries for providing type introspection. The library gives me the following guarantee: if a user used macro BOOST_DESCRIBE_STRUCT for some type T (and there are no ODR violations) than I can use `boost::describe::members` to see what those members are: their name, their type, and a pointer. If I want to use this data in a convenient way, I have to use another library atop of Boost.Describe. For instance, when I need to observe struct X as a tuple of references, I will write my own library, which: 1. Checks if Boost.PFR can figure it out automagically. If so, use this magic 2. If not, resort to Boost.Describe, and based on its interface, form a tuple of references. Did I capture it correctly? In that case, requesting high-level features in Boost.Describe is against its design goals. It is a low-level piece, not necessarily to be used directly. Regard, &rzej;

3 2

[Describe] Boost.Describe vs Boost.Fusion
by Andrzej Krzemienski 08 Mar '21

08 Mar '21

Hi Everyone (but mainly Peter), Boost.Spirit needs to have an index-based access to user defined types, as explained in the tutorial: https://www.boost.org/doc/libs/1_75_0/libs/spirit/doc/x3/html/spirit_x3/tut… Currently Boost.Spirit uses the interface of Boost.Fusion, and users are encouraged to use macros like BOOST_FUSION_ADAPT_STRUCT: https://www.boost.org/doc/libs/1_75_0/libs/fusion/doc/html/fusion/adapted/a… The first question is, can Boost.Describe's interface be plugged into Boost.Spirit? It is not that obvious to me for a couple of reasons. For instance, it would require an interface in Boost.Describe for answering the question, "has describe::members been specialized for type X"? The second question is, can is Boost.Describe capable of replacing the adapter macros in Boost.Fusion? For instance, Boost.Fusion allows the users to define and adapt a user defined type with one macro: https://www.boost.org/doc/libs/1_75_0/libs/fusion/doc/html/fusion/adapted/d… This is similar in concept to what macro BOOST_DEFINE_ENUM does for enums. What is the motivation behind allowing the definition of enums in this way but not classes (at least the aggregate classes). My general observation is that we have a number of libraries with overlapping goals: Boost.Describe, Boost.PFR, Boost.Fusion (the part for adapting UDTs) Maybe it is ok, but does it mean that there are so many incompatible use cases? Maybe there is a way to reduce this number. Regards, &rzej;

3 7

[Boost] [Describe] Review starts Monday 1st March 2021 - 10th March 2021
by Richard Hodges 08 Mar '21

08 Mar '21

The Boost formal review of the Describe starts Monday, taking place from March 1st, 2021 to March 10th, 2021 (inclusive). The library is authored by Peter Dimov. Documentation: https://pdimov.github.io/describe/doc/html/describe.html Source: https://github.com/pdimov/describe The library provides a simple means of providing reflection for structures and enums in C++. The documentation contains a number of common motivating examples, including: - A universal print function https://pdimov.github.io/describe/doc/html/describe.html#example_print_func… - JSON serialisation https://pdimov.github.io/describe/doc/html/describe.html#example_to_json Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including Describe as a Boost library. Please be explicit about your decision (ACCEPT or REJECT). Some other questions you might want to consider answering: - 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 which compiler(s)? 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? More information about the Boost Formal Review Process can be found at: http://www.boost.org/community/reviews.html The review is open to anyone who is prepared to put in the work of evaluating and reviewing the library. Prior experience in contributing to Boost reviews is not a requirement. Thank you for your efforts in the Boost community. They are very much appreciated. Richard Hodges - review manager of the proposed Boost.Describe library Peter is often available in the CppLang Slack #boost channel should you require any clarification not covered by the documentation, as am I. -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 home: +376841522 mobile: +376380212

9 19

[spirit] Custom error on rule level?
by Serguei TARASSOV 08 Mar '21

08 Mar '21

Hello, is it possible to have a custom error handler on the rule level (for every rule in the limit) ? Cannot find this point in docs/examples. I.e. when parsing following texts (// are inline comments): DO_JOB WITH not_a_opt1; // should raise "Option not_a_opt1 is unknown" DO_JOB WITH opt2 = 123; // should raise "Invalid value 123 for option opt2" Regards,

2 1

[build] Could not open a pull request
by Nikita Kniazev 05 Mar '21

05 Mar '21

It seems that forks of boostorg/build switched their parent automatically and I could not find a way to open a PR against boostorg/build. What is happening and how do I proceed?

6 8

boost.log's text_multifile_backend is not performant on windows - perhaps it should be documented?
by Nicholas Neumann 05 Mar '21

05 Mar '21

I recently moved a project to boost.log from a homemade logger. I had something like text_multifile_backend, so finding that as a drop-in replacement was awesome. Unfortunately, the performance when using text_multifile_backend on windows is really bad, because the repeated file close operations (one per log record) are unusually slow on windows. Repeatedly logging a string to the same file via text_multifile_backend results in throughput of about 200 log entries per second. Just to quickly prove it is unique to windows, I made a simple program that just opens, appends a single line, and then closes, an ofstream in a loop. On a high-end windows machine with nvme ssd, 1000 iterations takes 2600ms. On an older linux box with a sata ssd, the same takes 16ms. What do others think about adding a note in the documentation about this performance issue? It's bad enough that I think anyone on windows would want to avoid the backend. It's not the backend's "fault" at all; I could see some options for improving performance of the backend on windows, but they definitely complicate the simplicity of the current approach. (Side note - in googling the issue, other projects have been bitten - notably mercurial on windows - https://gregoryszorc.com/blog/2015/10/22/append-i/o-performance-on-windows/ )

5 27

[quickbook] Broken links generated in locally built docs
by Andrey Semashev 05 Mar '21

05 Mar '21

Hi, When I'm building QuickBook docs locally for Boost.Log, I'm seeing errors like the following in the end: Error: no ID for constraint linkend: "log.design". and so on for basically any section id that is used in the QuickBook [link] tag. In the resulting HTML documentation all such links point to the root directory where the HTML docs are located. Looking at the bin.v2/libs/log/doc/log_doc.xml file, for example, for the log.detailed.sink_frontends.sync is, it looks like <link> tags use the id that is specified in QuickBook: <link linkend="log.detailed.sink_frontends.sync"> but the actual section has a colon in front of the id: <section id=":log.detailed.sink_frontends.sync"> Is this a known issue and is there a workaround? I'm using DocBook XML from the Kubuntu package, which has version 4.5-9, and a freshly built QuickBook from develop. I used to build docs locally fine before, and did not change the configuration since, but I may have upgraded Kubuntu since I last built the docs. Thanks.

2 5

[release] 1.76.0 closes for major changes TOMORROW
by Marshall Clow 04 Mar '21

04 Mar '21

When: Wednesday, Mar 3, 2021 Description: Release closed for major code changes. Still open for serious problem fixes and docs changes without release manager review. Full calendar at: https://www.boost.org/development/ <https://www.boost.org/development/> — Marshall

3 3

Re: [boost] [Describe] Boost.Describe vs Boost.Fusion
by Nikita Kniazev 02 Mar '21

02 Mar '21

> Or have Spirit perform a check: if `describe::members` is found use it, otherwise fall back to Boost.Fusion. Spirit uses Fusion iterator_range internally, it will require to find/write a replacement that will work with both libraries.

1 0

AVL Databases and Boost Serialization in C++
by Benedict NNcNannara 02 Mar '21

02 Mar '21

AVL Databases were invented in C# and Java in 2016. More recently (2022) AVL Databases were invented in C++. They were a port of the C# code back to C++. In fact, the port was of a larger system - The Generic Language. Boost Serialization Library was used to serialize a general datatype t in set<t>. This applies to the C++ Variant of AVL Databases, The Generic Language Compiler uses AVL Databases to store its code. Execution occurs directly out of the code database, thus no loader is required. In fact the multithreaded, monolithic runtime is very fast compared to the C# version which is now obsolete. uuindouus.zip <https://drive.google.com/file/d/1NhEEmfZMf5yGbnsTAHH1N-XAjPCbczAy/view?usp=…>

5 5

1.76 schedule?
by John Maddock 01 Mar '21

01 Mar '21

Just noticed that the calendar has master closed for breaking changes from yesterday... I was hoping to do a Math & Multiprecision release, but they drop C++03 and have some massive restructuring/changes as a result. On the plus side they're better tested than they probably ever have been. So... too late for 1.76 or not? Thanks, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

4 4