- Boost - lists.preview.boost.org

[Boost] [Describe] library submission - last call for reviews from the community
by Richard Hodges 11 Mar '21

11 Mar '21

A friendly reminder that the review period for [Boost.Describe] will finish at the end of tomorrow - 10th March 2021 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. Please submit your review to the Boost mailing list: boost(a)lists.boost.org -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 home: +376841522 mobile: +376380212

3 6

[release] Reminder about 1.75.0 release notes
by Marshall Clow 11 Mar '21

11 Mar '21

The master branch is closing on Wednesday for the 1.75.0 release. If you have information that should go into the release notes, now’s the time to add it. Create a PR against https://github.com/boostorg/website/blob/master/feed/history/boost_1_75_0.q… <https://github.com/boostorg/website/blob/master/feed/history/boost_1_75_0.q…> — Marshall

2 3

[release] Release notes for 1.76.0
by Marshall Clow 11 Mar '21

11 Mar '21

If you have information that should go into the release notes, now’s a good time to add it. Create a PR against https://github.com/boostorg/website/blob/master/feed/history/boost_1_76_0.q… — Marshall

1 0

[Geometry] Proposing a project idea for GSOC 2021
by Siddharth Kumar 11 Mar '21

11 Mar '21

Hey, This is Siddharth Kumar. I have been working on the Boost.Geometry library for the past 2-3 months. I would like to propose a project idea about adding features for 3d-geometries, especially polyhedral surfaces which includes:- 1. Defining a geometry for the polyhedral surfaces. 2. Read and write features for the polyhedral surfaces. 3. Defining functions for the properties of polyhedral surfaces like volume, surface area, etc. This implementation will help in the direct use of the geometry in such algorithms, which are not yet implemented for the 3d-geometries or don’t provide compatible results when working with 3d-shapes, as they give points as an output rather than taking a geometry. For example- The convex hull <https://github.com/boostorg/geometry/issues/683> doesn’t handle 3d geometries correctly, because there is no 3d geometry defined that can handle the result of the algorithm. I have already submitted a PR <https://github.com/boostorg/geometry/pull/789> (yet to be merged), which defines the geometry for polyhedral surfaces, and also includes wkt read and write features, I am willing to work on other properties of the polyhedral surfaces as a project for GSOC 2021. I am looking for a mentor who is willing to guide me in this project. Thanks

2 2

[Describe] Andrzej's review.
by Andrzej Krzemienski 10 Mar '21

10 Mar '21

Hi Everyone, This is my review of the Boost.Describe library. I recommend that the library should be **ACCEPTED** into Boost. The goal of the library is clearly specified, and addresses real world needs. The examples (JSON serialization, printing) are convincing, and the number of reviews saying "I needed it for a while" reassure that it will be useful. The library is well designed. I mean the separation into macros declaring the "reflection lsts", and then functions operating on those lists. The documentation, in connection with the clear design, makes it easy to learn and use the library. The only issues I had was with the modifiers enum: I had to look into the implementation to understand how some values work. Regarding the implementation, I only had a superficial look. One thing I observed is that the implementation is very short! When I tried to combine all headers into one, in order to test it on WandBox, I discovered that it is less than 600 lines. You can see it here: https://wandbox.org/permlink/rkAtPCbAsqNzVRMV The only issue I have is the names that start with the underscore that can potentially end up in the global namespace, which by my reading of the C++ Standard is UB. I have spent a couple of hours testing toy examples, reading the docs, and looking at the implementation. I used GCC 9.2.0 on MinGW and GCC 10.1.0 on WandBox. All worked fine. Regarding my previous concerns about the "N+1" problem (an overlap with other libraries), I no longer have it. Boost.Describe is for class and enum authors to offer a reflection information for whoever wants it. A library like Boost.Fusion is for working with fusion sequences. Only as convenience, it provides a way to adapt a user defined class as a fusion sequence, but if it wants, it can use Boost.Describe lists as an alternative way of providing the adaptation. My two real-life use cases for a reflection like this was: 1. Adapting aggregates for Boost.Spirit. It looks like even Boost.FPR would do. 2. Printing and implementing swap() and hash() for my types. So far I had to do it manually, so I am looking forward to having this library in Boost. Finally, I would like to thank Peter for writing and sharing this library. Regards, &rzej;

1 0

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

feature for C++ standards compliance
by Robert Ramey 28 Feb '21

28 Feb '21

The serialization library is compatible with C++03 (and likely 98). And is tested regularly with C++ compilers with the -std switch set to this mode. The recent changes to the math library have broken about 5 tests in the serialization library. Since this breakage is in a few tests only and not in the library itself, I'd like to suppress these tests when the being tested with a C++03 compiler. I've suppressed tests which are conditional on C++ features which are not supported and this has worked well for my purposes. I'd like to do the same for a couple of tests which are conditional on usage of the math library and standards versions < C++11. Any B2/CMake experts want to help an old guy out?

8 19

New PropertyTree maintainer
by Glen Fernandes 27 Feb '21

27 Feb '21

Richard Hodges has kindly agreed to become the new maintainer of Boost.PropertyTree. Many thanks, Richard. Please update meta/libraries.json accordingly. Glen

1 0

Google Summer of Code follow-up
by Radu Cosma 26 Feb '21

26 Feb '21

Dear all, A couple of weeks ago I wrote an email inquiring about how to approach applying to contribute to your project through the GSoC opportunity. I did not seem to get any responses, is this the right place to ask? If not, could you please point me to a contact person that I can talk to? I am very interesting in contributing to this project and would really like to know how I can help. I am extremely familiar with the entirety of the C++20 standard, besides some final template (and concepts) features that I am still learning about, and would love the challenge of using those skills in the context of contributing to the Boost libraries. Thank you in advance and have a nice day! Kind regards, Radu Cosma

6 10

Introduction
by Samrat Patel 25 Feb '21

25 Feb '21

Hello Boost C++ Community, I am Samrat from Delhi Technology University and currently, I am pursuing my bachelor's in Computer Engineering(CoE). I have 3 years of experience in C++. I am extremely eager and excited about contributing to various projects of Boost C++. I am willing to participate in GSOC'21 with Boost C++. I would feel indebted if you could guide me in this regard. Regards Samrat Patel

4 3

property_tree in need of a maintainer
by Richard Hodges 25 Feb '21

25 Feb '21

Dear all, I am offering to become the/a maintainer of property_tree as part of my work for the C++ Alliance. Sincerely, -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 home: +376841522 mobile: +376380212

3 3

Reminder: Describe needs a review manager
by Peter Dimov 25 Feb '21

25 Feb '21

This is a reminder that my library Describe https://github.com/pdimov/describe https://pdimov.github.io/describe/doc/html/describe.html needs a review manager. Describe is a library that allows programmers to annotate their classes (and enumerations) in order to enable simple reflection. It provides a very important fundament on which other libraries can build upon to provide automatic support for user-defined types. For example, given an annotated type, Boost.JSON can automatically provide conversions from/to json::value. Boost.ContainerHash can automatically provide a hash function hash_value for the type. Boost.Serialization can automatically provide serialization support. See the examples: https://pdimov.github.io/describe/doc/html/describe.html#example_to_json https://pdimov.github.io/describe/doc/html/describe.html#example_from_json https://pdimov.github.io/describe/doc/html/describe.html#example_serializat… Other JSON (and serialization) libraries already offer a similar mechanism, e.g. https://github.com/nlohmann/json#arbitrary-types-conversions. But since each library has its own private way to annotate types, a programmer needs to repeat the type annotations for every library he wants his type to be known to. This is unnecessary and undesirable, and a standard mechanism to describe types avoids it. Describe is intended to be this standard mechanism, and I believe that we need it in Boost sooner rather than later. Thanks in advance to whoever volunteers.

7 11

Re: [boost] Reminder: Describe needs a review manager
by Bjorn Reese 25 Feb '21

25 Feb '21

On 2021-02-23 19:56, Peter Dimov via Boost wrote: > Describe is a library that allows programmers to annotate their classes > (and enumerations) in order to enable simple reflection. It provides a > very important fundament on which other libraries can build upon to > provide automatic support for user-defined types. How does it differ from Boost.Fusion?

2 1

[boost-ext] Looking for Review Manager/s
by Krzysztof Jusiak 24 Feb '21

24 Feb '21

Hi, I just wanted to share, potentially useful for the Boost and C++ community, libraries and ask if anyone would be willing to become a Review Manager for any of them? [boost-ext] (https://github.com/boost-ext) is a collection of C++ libraries with aspirations to be included in Boost. Libraries can be characterized by: * Modern C++ (>= C++14) * Header/Single Module only * No dependencies ATM, [boost::ext] consists of four core libraries: * DI - Dependency Injection Library overview: standard: C++14 single header with no dependencies (neither STL nor Boost is required) release: 1.2.0 (first release - 2014) key features: - supports macro-free constructor injection - supports templates injection - quick compilation-times - highly optimized code generation try it online: https://godbolt.org/z/5qTKhf source code: https://github.com/boost-ext/di documentation: https://boost-ext.github.io/di/ * SML - State Machine Library overview: standard: C++14 single header with no dependencies (neither STL nor Boost is required) release: 1.1.4 (first release - 2016) key features: - much faster compilation-times than Boost.MSM (up to 60x faster) - highly optimized and customizable code generation - suitable for embedded systems try it online: https://godbolt.org/z/y99L50 source code: https://github.com/boost-ext/sml documentation: https://boost-ext.github.io/sml/ * UT - Unit Testing Framework overview: standard: C++20 single header with no dependencies (STL required) release: 1.1.8 (first release - 2019) key features: - macro-free - minimal boilerplate - fast compilation-times and execution try it online: https://godbolt.org/z/Jqb5Ye source code: https://github.com/boost-ext/ut documentation: https://boost-ext.github.io/ut * TE - Run-time polymorphism (type erasure) library overview: standard: C++17 single header with no dependencies (STL required) release: - key features: - simple interface - highly optimized code generation try it online: https://godbolt.org/z/xY9MEq source code: https://github.com/boost-ext/te documentation: https://github.com/boost-ext/te All libraries (except TE) were successfully deployed in the production systems. Some, such as DI and SML are used by well known/big IT companies as well. If anyone is interested in becoming a Review Manager for any of the libraries, I'd really appreciate it and I'll more than happy to address any issues/requests before the review as well as help with any process-related tasks. Thank you very much, -Kris

12 43

Getting stated with boost and CMake
by pbristow＠hetp.u-net.com 24 Feb '21

24 Feb '21

Having spent a decade watching the Cmake versus bjam/b2 battle, I had thought it wise to wait until the dust has settled. It would appear that the enthusiasm for CMake and Boost is much greater among consumers than producers ☹ But recently I have been working on a project that is possible Boost library and thought that I would dip my toe in the water. After some research, I am still puzzled how I should replace a simple b2/bjam program (say a classic “hello World”) that is run like this \example > b2 -a toolset=msvc,gcc,clang cxxstd=14 release > my_log.log The jamfile contains run hello_world.cpp ; # Simplest hello_world, no other includes apart from iostream. And the b2 run .log contains some outputs of "Hello world" and 3 nice **passed** lines and ...updated 3(?) targets..., one for each compiler (and version too, perhaps with some potentially using build info too), and return exit_success value. (I also would expect to get a simple setup to run a test using the /included version of unit_test_framework. Trying to walk before I fall over running, I have avoided any pre-compiler libraries, at least at first.) After some research (getting as far as generating a Visual Studio project, where I can intervene manually to build and run my hello_world program), I am still unclear how to replicate this b2 test to end with a .exe run and some log file with pass/fail indications. I am of course building on Windows 10 with three recent versions of MSVC, GCC and Clang compilers working, and in my bjam/b2 user-config.jam. Advice from less-than-novice CMakers most welcome. Thank you. Paul

1 0

GSoC 2021 new policies
by Pranam Lashkari 23 Feb '21

23 Feb '21

Hello, To all the potential mentors and students this year GSoC is different from all the previous seasons, so whenever you are planning/proposing/adding a project in GSoC this year, keep the following things in mind: *Smaller project size** - *all students participating in the 2021 program will be working on a 175 hour project (instead of a 350 hr project). *Shortened coding period* - the *coding period will be 10 weeks* with a lot more flexibility for the mentor and student to decide together how they want to spread the work out over the summer. *2 evaluations (instead of 3)* - There will be an evaluation after 5 weeks and the final evaluation will take place after the 10th week. -- Thank you, Pranam Lashkari, https://lpranam.github.io/

1 0

Releasing property_tree updates
by Jared McIntyre 20 Feb '21

20 Feb '21

I noticed there are several updates that have merged into the develop branch for property_tree, but it seems none of them have made it into master for release. Is there any chance that a new version with the fixes may be pushed out in a future release? Thanks, Jared

2 1

boost test: first test organization examples using deprecated init_unit_test_suite?
by Dennis Luehring 15 Feb '21

15 Feb '21

according to this example, i should use init_unit_test_suite https://www.boost.org/doc/libs/1_75_0/libs/test/doc/html/boost_test/tests_o… but it seems that init_unit_test_suite function is deprecated (starting with 1.59) https://www.boost.org/doc/libs/1_75_0/libs/test/doc/html/boost_test/adv_sce… so its unclear to me if i should (still) use this deprecated function or go witht BOOST_AUTO_TEST_SUITE/BOOST_AUTO_TEST_CASE

1 0

[build] "Unknown target type EXE"
by John Maddock 09 Feb '21

09 Feb '21

I've managed to get various architectures tested in qemu-emulation in this PR: https://github.com/boostorg/config/pull/366, with help from https://github.com/uraimo/run-on-arch-action However, for armv7 alone I see: /home/runner/work/config/boost-root/tools/build/src/build/type.jam:158: in type.validate from module type error: Unknown target type EXE (builtin):-1: in sequence.transform from module sequence /home/runner/work/config/boost-root/tools/build/src/build/generators.jam:239: in generator.__init__ from module object(installed-exe-generator)@4 /home/runner/work/config/boost-root/tools/build/src/tools/stage.jam:568: in class(a)installed-exe-generator.__init__ from module object(installed-exe-generator)@4 /home/runner/work/config/boost-root/tools/build/src/kernel/class.jam:90: in new from module class /home/runner/work/config/boost-root/tools/build/src/tools/stage.jam:596: in load from module stage /home/runner/work/config/boost-root/tools/build/src/kernel/modules.jam:295: in import from module modules /home/runner/work/config/boost-root/tools/build/src/tools/builtin.jam:27: in load from module builtin /home/runner/work/config/boost-root/tools/build/src/kernel/modules.jam:295: in import from module modules /home/runner/work/config/boost-root/tools/build/src/build-system.jam:12: in load from module build-system /home/runner/work/config/boost-root/tools/build/src/kernel/modules.jam:295: in import from module modules /home/runner/work/config/boost-root/tools/build/src/kernel/bootstrap.jam:139: in boost-build from module /home/runner/work/config/boost-root/boost-build.jam:17: in module scope from module This is while running ./b2 headers. The initialization/setup code is the same for each architecture as they're run in a GHA matrix so I don't think I've goofed in the CI script. Anyone any ideas what might cause this? Many thanks, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 1

New Boost.Build regression/failure
by John Maddock 08 Feb '21

08 Feb '21

This: https://ci.appveyor.com/project/jzmaddock/config/builds/37592647/job/l6ogy7… Has just started failing. Any ideas anyone? Thanks, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

4 8

[Flyweight] Hidden symbol visibility
by Deniz Bahadir 08 Feb '21

08 Feb '21

Hi there, I recently made some interesting observation regarding Boost.Flyweight and (hidden) symbol visibility and have now some questions regarding this. Background story: ----------------- In our company's code base we have been using Boost.Flyweight for several years now, compiling it with GCC (and Clang) and it worked just fine. (Thanks for it!) However, lately we are trying to apply hidden symbol visibility to our code base and some of our unit-tests started failing mysteriously. After some intensive investigation I found out that it seems to be due to how we used Boost.Flyweight. We are instantiating it with some custom types, using the default `boost::flyweights::static_holder` class, and are compiling it into a shared library A. However, these Boost.Flyweight types are not only used within that shared library A but also in some other shared library B and in some unit-test executables which link against shared library A. (And these unit-tests started failing.) Observations: ------------- Reading the documentation of Boost.Flyweight and looking at the header `boost/flyweight/static_holder.hpp` I realized that we should have used `boost::flyweights::intermodule_holder` in the first place instead of `boost::flyweights::static_holder`, because we were using Boost.Flyweight from different shared libraries. Still, with non-hidden visibility applied everything always worked correctly even when using `boost::flyweights::static_holder`. Looking at the generated symbols in the different shared libraries I realized that these `static_holder` class types were marked as "unique global symbol" (an GNU extension to the standard set of ELF symbol bindings). So, all shared libraries and executables still used the same single instance of that `static_holder` class (which is the reason why everything worked). With hidden symbol visibility applied by default, these symbols are now marked as local symbols (from the BSS section). So, each shared library as well as the executables have their own version of the `static_holder` class types (which would explain why the equality-comparisions between different Boost.Flyweight variables in our unit-tests now started failing). If I understand it correctly, using `boost::flyweights::intermodule_holder` is the right thing to do, in particular with hidden symbol visibility. Questions: ---------- 1. However, apart from longer program startup times, what other disadvantages might it have to use the `intermodule_holder` instead of the `static_holder` (assuming it still would be marked as "unique global symbol")? 2. And if, as it seems, `static_holder` has some advantages in general, would it be possible to (maybe conditionally) mark the `static_holder` (and/or `static_holder_class`) class with `BOOST_SYMBOL_VISIBLE` or something similar to allow using it even with hidden symbol visibility from different shared libraries? - Only applying default visibility to the template instantiations is ignored by GCC (with warning: "type attributes ignored after type is already defined [-Wattributes]"). - Besides, the C++ standard does not allow applying C++ attributes to template instantiations. (There was a proposal for allowing it, wg21.link/p0537, but I do not know what happened to it.) 3. Would you have any other recommendations or suggestions I did not think about? Thanks for any help or opinion, Deniz -- BENOCS GmbH Dipl.-Inform. Deniz Bahadir Reuchlinstr. 10 D 10553 Berlin Germany Phone: +49 - 30 / 577 0004-22 Email: deniz.bahadir(a)benocs.com www.benocs.com Board of Management: Stephan Schroeder, Dr.-Ing. Ingmar Poese Commercial Register: Amtsgericht Bonn HRB 19378

2 2

BinTray is going away....
by Marshall Clow 06 Feb '21

06 Feb '21

My Friday morning email: > Thank you for supporting JFrog through your use of Bintray. We are and continue to be a community-focused company, and in the spirit of transparency we’re giving you advance notice that as of May 2021, we will be sunsetting Bintray. Just a heads up for now. — Marshall

2 1

Wrong class export/visibility setting for shared libs in many Boost libs
by Alexander Grund 02 Feb '21

02 Feb '21

Hi Boost maintainers, TLDR: Check your classes if they use BOOST_*_DECL and change that to BOOST_SYMBOL_VISIBLE In Boost.ProgramOptions I discovered an issue as a user, where I was unable to catch an exception thrown from the shared Boost library in an executable when both are build with hidden visibility. It turns out the exception class was marked with BOOST_PROGRAM_OPTIONS_DECL which evaluates to "visible" when building the DLL but to nothing when using it. This makes the linker (in theory) mark the typeinfo as hidden which means that the class thrown by Boost and the one tried to catch are unrelated. See https://gcc.gnu.org/wiki/Visibility > Symbol visibility is "default" by default but if the linker encounters just one definition with it hidden - just one - that typeinfo symbol becomes permanently hidden (remember the C++ standard's ODR - one definition rule). This is pretty clear that the current approach done by some Boost libraries doesn't/shouldn't work and BOOST_SYMBOL_VISIBLE should be used instead (or BOOST_SYMBOL_IMPORT should expand to BOOST_SYMBOL_VISIBLE. This depends on how MSCV/Win32 platforms handle class visibility as on Win32 BOOST_SYMBOL_VISIBLE expands to nothing. Maybe someone can clarify here.) As another datapoint: https://github.com/boostorg/config/blob/5bcaa933b55dd58797775d87605a6cdef4a… documents BOOST_SYMBOL_VISIBLE as the macro to be used for this. Libraries which are (very likely) affected by this (quick grep) include: Chrono Container Context Contract Coroutine Fiber Filesystem IOStreams JSON Locale MPI ProgramOptions Python Regex Test Thread Timer Seemingly Linux platforms are less strict in actually enforcing this, due to reason unknown to me. See my SO question: https://stackoverflow.com/questions/65951466/why-can-a-thrown-exception-wit… Reason why this went undetected so far are the above (works on some Linux, fails on e.g. OSX) and that user programs may often not be build with hidden visibility AND rely on the exact same typeinfo from the Boost library (most prominent: exceptions, dynamic_cast) Regards, Alex

5 40

Re: [boost] Wrong class export/visibility setting for shared libs in many Boost libs
by Peter Dimov 02 Feb '21

02 Feb '21

E.g. https://godbolt.org/z/vM6Gxd -----Original Message----- From: Peter Dimov Sent: Tuesday, February 02, 2021 17:01 To: boost(a)lists.boost.org Subject: Re: [boost] Wrong class export/visibility setting for shared libs in many Boost libs Niall Douglas wrote: > I seem to be having difficulty communicating this to anyone here, so > here's a godbolt: > > https://godbolt.org/z/jv5Y75 But you've provided a definition for thirdpartylib_nothidden. This is not the case under discussion. The case under discussion is making BOOST_SYMBOL_IMPORT imply _VISIBLE, which translates to a default visibility attribute on the _declaration_ of thirdpartylib_nothidden.

1 0

Google Summer of Code
by Radu Cosma 30 Jan '21

30 Jan '21

Good afternoon, My name is Radu Cosma and I would like to be a contributor to the Boost C++ Libraries in the context of Google Summer of Code 2021 (as a start :) ). I understand that the topics have yet to be posted and that there is a competency test involved. Could you please tell me the relevant information regarding this and the application process? Thank you in advance! Kind regards, Radu Cosma

1 0

What's the reason Boost.Asio tss_ptr doesn't use __declspec(thread) on Windows?
by Groke, Paul 29 Jan '21

29 Jan '21

Hi, I've noticed that Boost.Asio's tss_ptr implementation doesn't use __declspec(thread) on Windows, except when compiling for WinRT. Instead it uses the win_tss_ptr implementation - which will cause a crash when there's no free TLS index. (There are static tss_ptr instances and loading a DLL where a ctor of a static variables throws a C++ exception seems to cause a crash -- no surprise there). AFAIK using implicit TLS via __declspec(thread) should fix this so that loading a DLL either works or fails gracefully. One problem that I know of with implicit TLS is that it fails catastrophically on Windows versions before Vista. Since WinRT wasn't available on pre-Vista versions, this might be a reason to restrict it to WinRT. But I don't know if there are/were other reasons to restrict use of implicit TLS to WinRT. So... is there another reason? If there's no other reason, that would be great, because we don't have to support pre-Vista versions. Meaning we could simply patch Boost.Asio to use implicit TLS for MSVC in general. Regards, Paul Groke

1 0

Have we become too Intel x64 centered?
by John Maddock 28 Jan '21

28 Jan '21

I have no solution for this, but I note that neither do we have CI, nor tests on https://www.boost.org/development/tests/develop/developer/summary.html that aren't Intel x86. The compiler list has shrunk to msvc/clang/gcc as well. I note that at least in theory, other platforms/architectures could be integrated into Drone CI (either the CppAlliance one, or our own), but someone would have to offer to host the clients running the tests. Any thoughts/solutions? Cheers, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

21 54

Introduction
by Aman Verma 28 Jan '21

28 Jan '21

Hello Boost C++ Community, I am Aman from Indian Institute of technology Kanpur and currently, I am pursuing my bachelor's in Electrical engineering. I have 3 years of experience in C++. I am extremely eager and excited about contributing to various projects of Boost C++. I am willing to participate in GSOC'21 with Boost C++. I have gone through the project proposals and I find myself interested in the following projects: 1. ublas 2. Multiprecision 3. Geometry I would great if I could connect with the respective mentors and move onto further steps. Regards Aman

2 1

boost.numpy functions are throwing unresolved extern symbol link errors
by Max Fetz 20 Jan '21

20 Jan '21

Hello Boost-Community I have asked the following question everywhere but nowhere has it been answered. I have now been advised to ask here. I really hope there is someone on this mail list who can help me. Unfortunately I don't have much time left and would be very grateful for an answer. With kind regards Max My Question: I'm using normal Boost.NumPy functions in C++ like ndarray::get_data(), and I get a "reference to unresolved external symbol" error. The .lib's are linked and I have no approach on how to solve the error. I am using Boost 1.74. Here is a Code example: #include<boost/python/numpy.hpp> using namespace boost; void func(python::object _obj) { python::numpy::ndarray my_ndarray = python::extract<boost::python::numpy::ndarray>(_obj.attr("Member_01")); char* data = my_ndarray.get_data(); } BOOST_PYTHON_MODULE(ogwa_acc) { python::def("func", func); } Thats the one of the unresolved symbols: ""__declspec(dllimport) public: char * __cdecl boost::python::numpy::ndarray::get_data(void)const " (_imp?get_data@ndarray@numpy@python@boost@@QEBAPEADXZ)" I am using the normal Visual Studio linker and this is my linker config: /OUT:"D:\OthelloGame_withAI\x64\Debug\ogwa_acc.pyd" /MANIFEST /NXCOMPAT /PDB:"D:\OthelloGame_withAI\x64\Debug\ogwa_acc.pdb" /DYNAMICBASE "boost_numpy38-vc142-mt-gd-x64-1_74.lib" "boost_numpy38-vc142-mt-x64-1_74.lib" "boost_python38-vc142-mt-gd-x64-1_74.lib" "boost_python38-vc142-mt-x64- 1_74.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /IMPLIB:"D:\OthelloGame_withAI\x64\Debug\ogwa_acc.lib" /DEBUG /DLL /MACHINE:X64 /INCREMENTAL /PGD:"D:\OthelloGame_withAI\x64\Debug\ogwa_acc.pgd" /SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"x64\Debug\ogwa_acc.pyd.intermediate.manifest" /ERRORREPORT:PROMPT /NOLOGO /LIBPATH:"C:\Program Files\Python38\libs" /LIBPATH:"D:\OthelloGame_withAI\Third-Party\boost_1_74_0\finished_libs" /TLBID:1 D:\OthelloGame_withAI\Third-Party\boost_1_74_0\finished_libs is the location of: boost_numpy38-vc142-mt-gd-x64-1_74.lib; boost_python38-vc142-mt-gd-x64- 1_74.lib; boost_numpy38-vc142-mt-x64-1_74.lib; boost_python38-vc142-mt-x64-1_74.lib

4 4

[build] b2 headers broken?
by John Maddock 16 Jan '21

16 Jan '21

Currently all CI seems to be failing during b2 headers, but with no obvious error message, see for example: https://drone.cpp.al/boostorg/multiprecision/23/1/2 Only possible thing I can see is: project-config.jam:10: syntax error at keyword in Anyone any ideas? Many thanks, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

3 5

Feedback desired for neural networks library
by Sergei Marchenko 11 Jan '21

11 Jan '21

Hi everyone, I have a template-based library with several common types of layers which can be assembled into various neural networks: https://github.com/svm-git/NeuralNet, and I would love to get community feedback on the overall design, any issues or missing features, and how interesting a library like that would be in general. I've been watching the trends and research reports in the AI/ML space, and I feel that the recent announcements of the successful models for image classification, computer vision or natural language processing, push the focus towards very complex and computationally intensive networks. However, I think that the idea behind multi-layer networks is very powerful, and is applicable in many domains, where even a small and lightweight model can be used successfully. I also think that if developers have an access to a library of building blocks that allows them to train and run NN anywhere a C++ code can run, it may encourage a lot of good applications. In the current state, the library is fairly small and should be easy to review. It was built with two main goals in mind: * Provide a collection of building blocks that share a common interface which allows plug'n'play construction of more complex NNs. * Compile-time verification of the internal consistency of the network. I.e. if a layer's output size does not match the next layer's input, it is caught at the very early stage. Once it seems like there is some consensus on the core design and usefulness of such library, I am willing to do the work necessary to make the library consistent with Boost requirements for naming convention, folder structure, unit tests etc. The library relies on the C++ 11 language features and has a dependency on just a few STL components, so I think it should be straightforward to merge into Boost. Best regards, Sergei Marchenko.

6 15

Can boost ASIO SSL run one way SSL?
by Jupiter 11 Jan '21

11 Jan '21

Hi, There is an example for running boost::asio::ssl for boost::asio::ip::tcp connection, it uses 2 way SSL which client uses the key and certificates to have two way SSL handshake. My boss asked me if it can be used for one way SSL similar to HTTPS, I don't think so, but I could be wrong. Appreciate your advice. Thank you. Kind regards, jupiter

2 3

Problem building Ceph 14.2.15 with libboost 1.74.0
by Thomas Goirand 07 Jan '21

07 Jan '21

Hi, I'm the Debian package maintainer for Ceph. Ceph currently fails to build with latest libbost. Here's the build log: /root/ceph/src/common/async/completion.h:194:29: error: 'boost::asio::executor_work_guard<boost::asio::execution::any_executor<boost::asio::execution::context_as_t<boost::asio::execution_context&>, boost::asio::execution::detail::blocking::never_t<0>, boost::asio::execution::prefer_only<boost::asio::execution::detail::blocking::possibly_t<0> >, boost::asio::execution::prefer_only<boost::asio::execution::detail::outstanding_work::tracked_t<0> >, boost::asio::execution::prefer_only<boost::asio::execution::detail::outstanding_work::untracked_t<0> >, boost::asio::execution::prefer_only<boost::asio::execution::detail::relationship::fork_t<0> >, boost::asio::execution::prefer_only<boost::asio::execution::detail::relationship::continuation_t<0> > >, void>::executor_type' {aka 'class boost::asio::execution::any_executor<boost::asio::execution::context_as_t<boost::asio::execution_context&>, boost::asio::execution::detail::blocking::never_t<0>, boost::asio::execution::prefer_only<boost::asio::execution::detail::blocking::possibly_t<0> >, boost::asio::execution::prefer_only<boost::asio::execution::detail::outstanding_work::tracked_t<0> >, boost::asio::execution::prefer_only<boost::asio::execution::detail::outstanding_work::untracked_t<0> >, boost::asio::execution::prefer_only<boost::asio::execution::detail::relationship::fork_t<0> >, boost::asio::execution::prefer_only<boost::asio::execution::detail::relationship::continuation_t<0> > >'} has no member named 'defer'; did you mean 'prefer'? 194 | w.second.get_executor().defer(std::move(f), alloc2); and 3 more like this. The code doing this is in src/common/async/completion.h: void destroy_defer(std::tuple<Args...>&& args) override { auto w = std::move(work); auto f = bind_and_forward(std::move(handler), std::move(args)); RebindAlloc2 alloc2 = boost::asio::get_associated_allocator(handler); RebindTraits2::destroy(alloc2, this); RebindTraits2::deallocate(alloc2, this, 1); w.second.get_executor().defer(std::move(f), alloc2); } void destroy_dispatch(std::tuple<Args...>&& args) override { auto w = std::move(work); auto f = bind_and_forward(std::move(handler), std::move(args)); RebindAlloc2 alloc2 = boost::asio::get_associated_allocator(handler); RebindTraits2::destroy(alloc2, this); RebindTraits2::deallocate(alloc2, this, 1); w.second.get_executor().dispatch(std::move(f), alloc2); } void destroy_post(std::tuple<Args...>&& args) override { auto w = std::move(work); auto f = bind_and_forward(std::move(handler), std::move(args)); RebindAlloc2 alloc2 = boost::asio::get_associated_allocator(handler); RebindTraits2::destroy(alloc2, this); RebindTraits2::deallocate(alloc2, this, 1); w.second.get_executor().post(std::move(f), alloc2); } Has the boost API changed? If so, how to fix the above code? Thanks a lot to anyone helping me fixing this, Cheers, Thomas Goirand (zigo)

2 2

[uBlas] [Tensor] multiprecision and FFT?
by Janek Kozicki 07 Jan '21

07 Jan '21

Cem Bassoy via Boost said: (by the date of Wed, 6 Jan 2021 10:32:15 +0100) > Please consider to use and contribute to *Boost.uBlas* Hi, Does it work with boost::multiprecision types? In particular I am interested in types listed here: http://yade-dem.org/doc/HighPrecisionReal.html Does it support FFT ? In particular I am interested in replacing my very crude NDimTable class with your code: https://gitlab.com/cosurgi/trunk/-/blob/addQuantumMechanics_FixEnum_FixReba… I am about to start refactoring this part of the code, when I noticed your post. best regards Janek -- Janek Kozicki, PhD. DSc. Arch. Assoc. Prof. Gdańsk University of Technology Faculty of Applied Physics and Mathematics Department of Theoretical Physics and Quantum Information -- http://yade-dem.org/ http://pg.edu.pl/jkozicki (click English flag on top right)

2 3

C++11 on up Boost libraries
by Edward Diener 04 Jan '21

04 Jan '21

In my effort to set the meta information of 'cxxstd' for the appropriate C++11 on up libraries, my PRs for these libraries have been kindly merged to 'develop' by the library maintainers: beast callable_traits context convert coroutine2 fiber geometry gil hana histogram hof json leaf mp11 nowide outcome pfr process safe_numerics static_string stl_interfaces variant2 yap If anyone knows of any other current library which is a C++11 on up library, please tell me. My testing showed that all other Boost libraries will work in C++03 mode, but maybe I missed some other library which is a C++11 on up library. Needless to say other libraries have noted their attention to move from C++03 to C++11 in the near future. If any library does change the C++ mode necessary to use that library, I hope the maintainer(s) of that library will update the 'cxxstd' meta information appropriately. If we can get the website to work properly using the 'cxxstd' meta information, end-users should be able to know immediately whether a Boost library is usable depending on the C++ standard mode their are using.

10 20

Develop is broken on MSVC (b2 issue?)
by Antony Polukhin 04 Jan '21

04 Jan '21

I see a bunch of CI failures https://apolukhin.github.io/en/developer.html for different versions of MSVC. There are some complains on 'cl': compile-c-c++ ..\..\..\bin.v2\libs\type_index\test\track_13621.test\msvc-9.0\release\threading-multi\track_13621.obj 'cl' is not recognized as an internal or external command, operable program or batch file. call "..\..\..\bin.v2\standalone\msvc\msvc-9.0\msvc-setup.bat" amd64 >nul cl /Zm800 -nologo "track_13621.cpp" -Fo"..\..\..\bin.v2\libs\type_index\test\track_13621.test\msvc-9.0\release\threading-multi\track_13621.obj" -TP -DBOOST_TRAVISCI_BUILD /wd4675 /EHs /GR /O2 /Ob2 /W3 /MD /Zc:forScope /Zc:wchar_t /favor:blend -c -DBOOST_ALL_NO_LIB=1 -DNDEBUG "-I..\..\.." ...failed compile-c-c++ ..\..\..\bin.v2\libs\type_index\test\track_13621.test\msvc-9.0\release\threading-multi\track_13621.obj... Is that a known issue?

3 3

Regression Test Failures On develop branch
by Tom Kent 02 Jan '21

02 Jan '21

I just noticed that the develop branch has started to fail to run the develop branch, crashing early on in the run. The failures started sometime between 2020-12-31_03:52:29 PST (2020-12-31_11:52:29 UTC) (last good run) and 2020-12-31_06:57:54 PST (2020-12-31_14:57:54 UTC) (first failing run). These are still continuing with the latest develop branch. It looks like there were only a couple commits to boostorg/boost/develop in this window, and update to multiprecision (only changing meta/libraries.json) and a few changes to build. The error looks fairly non-descript... D:\teeks99-09\run\boost_root\status>"D:\teeks99-09\run\boost_bb\src\engine\bjam.exe" "-sBOOST_BUILD_PATH=D:\teeks99-09\run;D:\teeks99-09\run\boost_bb\src" "-sBOOST_ROOT=D:\teeks99-09\run\boost_root" "--boost=D:\teeks99-09\run\boost_root" "--boost-root=D:\teeks99-09\run\boost_root" "--boost-build=D:\teeks99-09\run\boost_bb\src" "--debug-configuration" -l300 toolset=msvc-11.0 -d2 preserve-test-targets=off --dump-tests -j8 address-model=64 --remove-test-targets --abbreviate-paths debug-symbols=off -m64 "--build-dir=D:\teeks99-09\run\results" 1>>"D:\teeks99-09\run\results\bjam.log" 2>&1 # Running Boost.Build tests Traceback (most recent call last): File "run.py", line 71, in <module> runner(root) File "D:\teeks99-09\run\boost_regression_src\regression.py", line 286, in __init__ self.main() File "D:\teeks99-09\run\boost_regression_src\regression.py", line 623, in main getattr(self,action_m)() File "D:\teeks99-09\run\boost_regression_src\regression.py", line 588, in command_regression self.command_test() File "D:\teeks99-09\run\boost_regression_src\regression.py", line 367, in command_test self.command_test_boost_build() File "D:\teeks99-09\run\boost_regression_src\regression.py", line 409, in command_test_boost_build "boost/bin.v2/libs/any/test/any_test.test")); WindowsError: [Error 3] The system cannot find the path specified: 'D:\\teeks99-09\\run\\results\\boost/bin.v2/libs/any/test/any_test.test\\*.*' At the end of my result-bjam.log file, I get this, but not sure if it is related. Performing configuration checks - default architecture : x86 - default address-model : 64-bit - symlinks supported : no - junctions supported : yes - hardlinks supported : yes - BOOST_COMP_GNUC >= 4.3.0 : no - has_icu builds : no - compiler supports SSE2 : yes - compiler supports SSE4.1 : yes - has synchronization.lib : yes - cxx11_constexpr : no - cxx11_decltype : yes - cxx11_hdr_tuple : no - cxx11_template_aliases : no - cxx11_variadic_templates : no - OpenCL : no - C++11 mutex : yes - has BCrypt API : yes - has stat::st_mtim : no - has stat::st_mtimensec : no - has stat::st_mtimespec : no - has stat::st_birthtim : no - has stat::st_birthtimensec : no - has stat::st_birthtimespec : no - has statx : no - has statx syscall : no - cxx11_auto_declarations : yes - cxx11_defaulted_functions : no - cxx11_final : yes - cxx11_hdr_mutex : yes - cxx11_lambdas : yes - cxx11_noexcept : no - cxx11_nullptr : yes - cxx11_rvalue_references : yes - cxx11_thread_local : no - cxx11_trailing_result_types : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam. note: to suppress this message, pass "--without-graph_parallel" to bjam. - cxx14_constexpr : no - cxx14_decltype_auto : no - cxx14_generic_lambdas : no - cxx14_return_type_deduction : no - cxx11_user_defined_literals : no - cxx11_alignas : no - iconv (libc) : no - iconv (separate) : no - icu : no - icu (lib64) : no - native atomic int32 supported : yes - has message compiler : yes - native syslog supported : no - pthread supports robust mutexes : no - compiler supports SSSE3 : yes - compiler supports AVX2 : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. - cxx11_static_assert : yes - std::fstream is moveable and swappable : yes - !BOOST_COMP_GNUC : yes - BOOST_COMP_GNUC >= 6.0 : no - !BOOST_COMP_CLANG : yes - BOOST_COMP_CLANG >= 4.0 : no - cxx14_variable_templates : no - BOOST_COMP_GNUC >= 4.7.4 : no error: No best alternative for ../libs/accumulators/test/accumulators_test_valarray next alternative: required properties: <link>static <target-os>linux <toolset>clang not matched next alternative: required properties: <link>static <target-os>darwin not matched next alternative: required properties: <link>static not matched error: No best alternative for ../libs/accumulators/test/accumulators_test_tail_variate_means next alternative: required properties: <link>static <toolset-msvc:version>14.0 <toolset>msvc not matched next alternative: required properties: <link>static not matched error: No best alternative for ../libs/accumulators/test/accumulators_tests_pot_quantile_and_weighted_tail next alternative: required properties: <link>static <target-os>linux <toolset-gcc:version>4.4.7 <toolset>gcc not matched next alternative: required properties: <link>static not matched error: No best alternative for ../libs/accumulators/test/accumulators_test_weighted_tail_variate_means next alternative: required properties: <link>static <target-os>linux <toolset-gcc:version>4.4.7 <toolset>gcc not matched next alternative: required properties: <link>static <toolset-msvc:version>14.0 <toolset>msvc not matched next alternative: required properties: <link>static not matched - cxx11_constexpr : no - cxx11_decltype : yes - cxx11_hdr_tuple : no - cxx11_template_aliases : no - cxx11_variadic_templates : no - OpenCL : no - has_atomic_lib builds : no - has_pthread_lib builds : no - has_rt_lib builds : no - Clang implicit fallthrough : no - int128 : no - cpp_lib_complex_udls : no - cpp_range_based_for_17 : no - cxx11_hdr_thread : yes - cxx11_variadic_macros : yes - cxx11_hdr_unordered_set : yes - mixed_cxxstd builds : yes - mixed_cxxstd builds : yes - cxx11_hdr_array : yes - cxx11_defaulted_functions : no - cxx11_trailing_result_types : no notice: [libjpeg] Using pre-installed library notice: [libjpeg] Condition notice: [zlib] zlib is already configured notice: [libpng] Using pre-installed library notice: [libpng] Condition notice: [libtiff] Using pre-installed library notice: [libtiff] Condition - cxx14_constexpr : no - cxx14_decltype_auto : no - cxx14_generic_lambdas : no - cxx14_return_type_deduction : no - cxx11_user_defined_literals : no - Checking for gmpxx.h : no - zlib : no - bzip2 : no - lzma : no - zstd : no - lzma : no (cached) - has_lzma_cputhreads builds : no - cxx11_alignas : no - message-compiler : yes - message-compiler : yes - cxx11_unified_initialization_syntax : no - cxx11_smart_ptr : yes - GCC libquadmath and __float128 support : no - cxx11_hdr_initializer_list : no - sfinae_expr : no - cxx11_inline_namespaces : no - cxx11_range_based_for : yes - libfftw3 : no - __float128 : no - has_ntl_rr builds : no - has_mpfr_class builds : no - has_mpreal builds : no - has_e_float builds : no - gcc visibility : no - long double support : yes - cxx17_if_constexpr : no - cxx17_std_apply : no - has_eigen builds : no - Intel _Quad datatype support : no - has_mpfr builds : no - cxx11_hdr_atomic : no - cxx11_hdr_future : yes - cxx11_hdr_chrono : yes - cxx11_hdr_random : yes - cxx11_allocator : no - 128-bit floatmax_t : no - cxx11_numeric_limits : yes - cxx11_explicit_conversion_operators : no - cxx11_function_template_default_args : no - BOOST_MULTI_INDEX_KEY_SUPPORTED defined : no - has_gmp builds : no - has_tommath builds : no - has_mpfi builds : no - has_float128 builds : no - has_intel_quad builds : no - has_mpc builds : no - has_is_constant_evaluated builds : no - has_constexpr_limits builds : no - has_gmp builds : no - has_mpfr builds : no - has_big_obj builds : no - has_f2c builds : no - cxx11_noexcept : no - cxx11_rvalue_references : yes - cxx11_static_assert : yes - std::fstream is moveable and swappable : yes - cxx11_hdr_chrono : yes - !BOOST_COMP_GNUC : yes - BOOST_COMP_GNUC >= 6.0 : no - !BOOST_COMP_CLANG : yes - BOOST_COMP_CLANG >= 4.0 : no - cxx14_variable_templates : no - cxx17_structured_bindings : no - cxx17_structured_bindings : no - compiler_supports_loophole builds : yes - compiler_supports_loophole builds : yes - cxx11_hdr_unordered_map : yes WARNING: Unable to construct ../libs/predef/test/info_as_objcpp of type RUN with these properties: <abi>ms <address-model>64 <architecture>x86 <asynch-exceptions>off <bc_hdr>lib <bc_no>all_yes <binary-format>pe <boost.beast.allow-deprecated>on <boost.beast.separate-compilation>on <context-impl>fcontext <coverage>off <debug-store>object <debug-symbols>off <deduced-address-model>64 <deduced-architecture>x86 <define>BOOST_ALL_NO_LIB=1 <define>BOOST_BEAST_ALLOW_DEPRECATED <define>BOOST_BEAST_SEPARATE_COMPILATION <dependency>object(file-target)@110440 <embed-manifest-via>linker <embed-manifest>on <exception-handling>on <extern-c-nothrow>off <hardcode-dll-paths>true <host-os>windows <implicit-dependency>object(notfile-target)@92787 <include>.. <include>/D:/teeks99-09/run/boost_root/libs/predef/include <inlining>off <install-dependencies>off <link>shared <local-visibility>hidden <location-prefix>info_as_objcpp.test <midl-robust>yes <midl-stubless-proxy>yes <optimization>off <os>NT <pch>on <preserve-test-targets>off <profiling>off <python-debugging>off <python.interpreter>python <python>3.8 <relevant>define:<relevant>toolset <relevant>link:<relevant>toolset <relevant>python.interpreter:<relevant>python <relevant>python.interpreter:<relevant>target-os <relevant>threading:<relevant>runtime-link <relevant>threading:<relevant>toolset <relevant>toolset <response-file>auto <rtti>on <runtime-debugging>on <runtime-link>shared <stdlib>native <strip>off <suppress-import-lib>false <symlink-location>project-relative <tag>@Jamfile<D:\teeks99-09\run\boost_root>%Jamfile<D:\teeks99-09\run\boost_root>.tag <target-os>windows <test-info>always_show_run_output <testing.execute>on <threadapi>win32 <threading>multi <toolset-msvc:version>11.0 <toolset>msvc <user-interface>console <variant>debug <vectorize>off <visibility>hidden <warnings-as-errors>off <warnings>on <windows-api>desktop <xsl:param>boost.defaults=Boost WARNING: Considered these as possible generators: WARNING: testing.expect-success with source types { RUN_OUTPUT } and requirements { } WARNING: Unable to construct ../libs/predef/test/info_as_objc of type RUN with these properties: <abi>ms <address-model>64 <architecture>x86 <asynch-exceptions>off <bc_hdr>lib <bc_no>all_yes <binary-format>pe <boost.beast.allow-deprecated>on <boost.beast.separate-compilation>on <context-impl>fcontext <coverage>off <debug-store>object <debug-symbols>off <deduced-address-model>64 <deduced-architecture>x86 <define>BOOST_ALL_NO_LIB=1 <define>BOOST_BEAST_ALLOW_DEPRECATED <define>BOOST_BEAST_SEPARATE_COMPILATION <dependency>object(file-target)@110440 <embed-manifest-via>linker <embed-manifest>on <exception-handling>on <extern-c-nothrow>off <hardcode-dll-paths>true <host-os>windows <implicit-dependency>object(notfile-target)@92787 <include>.. <include>/D:/teeks99-09/run/boost_root/libs/predef/include <inlining>off <install-dependencies>off <link>shared <local-visibility>hidden <location-prefix>info_as_objc.test <midl-robust>yes <midl-stubless-proxy>yes <optimization>off <os>NT <pch>on <preserve-test-targets>off <profiling>off <python-debugging>off <python.interpreter>python <python>3.8 <relevant>define:<relevant>toolset <relevant>link:<relevant>toolset <relevant>python.interpreter:<relevant>python <relevant>python.interpreter:<relevant>target-os <relevant>threading:<relevant>runtime-link <relevant>threading:<relevant>toolset <relevant>toolset <response-file>auto <rtti>on <runtime-debugging>on <runtime-link>shared <stdlib>native <strip>off <suppress-import-lib>false <symlink-location>project-relative <tag>@Jamfile<D:\teeks99-09\run\boost_root>%Jamfile<D:\teeks99-09\run\boost_root>.tag <target-os>windows <test-info>always_show_run_output <testing.execute>on <threadapi>win32 <threading>multi <toolset-msvc:version>11.0 <toolset>msvc <user-interface>console <variant>debug <vectorize>off <visibility>hidden <warnings-as-errors>off <warnings>on <windows-api>desktop <xsl:param>boost.defaults=Boost WARNING: Considered these as possible generators: WARNING: testing.expect-success with source types { RUN_OUTPUT } and requirements { } - BOOST_OS_MACOS : no - BOOST_COMP_CLANG > 0.0.0 : no - BOOST_OS_LINUX == 0 : yes WARNING: Unable to construct ../libs/predef/test/info_as_objcpp of type RUN with these properties: <abi>ms <address-model>64 <architecture>x86 <asynch-exceptions>off <bc_hdr>lib <bc_no>all_yes <binary-format>pe <boost.beast.allow-deprecated>on <boost.beast.separate-compilation>on <context-impl>fcontext <coverage>off <debug-store>object <debug-symbols>off <deduced-address-model>64 <deduced-architecture>x86 <define>BOOST_ALL_NO_LIB=1 <define>BOOST_BEAST_ALLOW_DEPRECATED <define>BOOST_BEAST_SEPARATE_COMPILATION <dependency>object(file-target)@110440 <embed-manifest-via>linker <embed-manifest>on <exception-handling>on <extern-c-nothrow>off <hardcode-dll-paths>true <host-os>windows <implicit-dependency>object(notfile-target)@92787 <include>.. <include>/D:/teeks99-09/run/boost_root/libs/predef/include <inlining>off <install-dependencies>off <link>shared <local-visibility>hidden <location-prefix>info_as_objcpp.test <midl-robust>yes <midl-stubless-proxy>yes <optimization>off <os>NT <pch>on <preserve-test-targets>off <profiling>off <python-debugging>off <python.interpreter>python <python>3.8 <relevant>define:<relevant>toolset <relevant>link:<relevant>toolset <relevant>python.interpreter:<relevant>python <relevant>python.interpreter:<relevant>target-os <relevant>threading:<relevant>runtime-link <relevant>threading:<relevant>toolset <relevant>toolset <response-file>auto <rtti>on <runtime-debugging>on <runtime-link>shared <stdlib>native <strip>off <suppress-import-lib>false <symlink-location>project-relative <tag>@Jamfile<D:\teeks99-09\run\boost_root>%Jamfile<D:\teeks99-09\run\boost_root>.tag <target-os>windows <test-info>always_show_run_output <testing.execute>on <threadapi>win32 <threading>multi <toolset-msvc:version>11.0 <toolset>msvc <user-interface>console <variant>debug <vectorize>off <visibility>hidden <warnings-as-errors>off <warnings>on <windows-api>desktop <xsl:param>boost.defaults=Boost WARNING: Considered these as possible generators: WARNING: testing.expect-success with source types { RUN_OUTPUT } and requirements { } WARNING: Unable to construct ../libs/predef/test/info_as_objc of type RUN with these properties: <abi>ms <address-model>64 <architecture>x86 <asynch-exceptions>off <bc_hdr>lib <bc_no>all_yes <binary-format>pe <boost.beast.allow-deprecated>on <boost.beast.separate-compilation>on <context-impl>fcontext <coverage>off <debug-store>object <debug-symbols>off <deduced-address-model>64 <deduced-architecture>x86 <define>BOOST_ALL_NO_LIB=1 <define>BOOST_BEAST_ALLOW_DEPRECATED <define>BOOST_BEAST_SEPARATE_COMPILATION <dependency>object(file-target)@110440 <embed-manifest-via>linker <embed-manifest>on <exception-handling>on <extern-c-nothrow>off <hardcode-dll-paths>true <host-os>windows <implicit-dependency>object(notfile-target)@92787 <include>.. <include>/D:/teeks99-09/run/boost_root/libs/predef/include <inlining>off <install-dependencies>off <link>shared <local-visibility>hidden <location-prefix>info_as_objc.test <midl-robust>yes <midl-stubless-proxy>yes <optimization>off <os>NT <pch>on <preserve-test-targets>off <profiling>off <python-debugging>off <python.interpreter>python <python>3.8 <relevant>define:<relevant>toolset <relevant>link:<relevant>toolset <relevant>python.interpreter:<relevant>python <relevant>python.interpreter:<relevant>target-os <relevant>threading:<relevant>runtime-link <relevant>threading:<relevant>toolset <relevant>toolset <response-file>auto <rtti>on <runtime-debugging>on <runtime-link>shared <stdlib>native <strip>off <suppress-import-lib>false <symlink-location>project-relative <tag>@Jamfile<D:\teeks99-09\run\boost_root>%Jamfile<D:\teeks99-09\run\boost_root>.tag <target-os>windows <test-info>always_show_run_output <testing.execute>on <threadapi>win32 <threading>multi <toolset-msvc:version>11.0 <toolset>msvc <user-interface>console <variant>debug <vectorize>off <visibility>hidden <warnings-as-errors>off <warnings>on <windows-api>desktop <xsl:param>boost.defaults=Boost WARNING: Considered these as possible generators: WARNING: testing.expect-success with source types { RUN_OUTPUT } and requirements { } - zlib : no (cached) - bzip2 : no (cached) - lzma : no (cached) - zstd : no (cached) - zlib : no - bzip2 : no - lzma : no - zstd : no - auto_ptr : yes - cxx11_lambdas : yes - std_wstreambuf : yes - cxx11_hdr_forward_list : yes Happy new year! Tom

2 2

Re: [boost] Boost website changes and .'cxxstd`
by Donovan Dikaio 30 Dec '20

30 Dec '20

Hi Edward, you're right. The beta website link is https://beta.boost.org/ FYI, there is a file 'libraries.txt' in the source codes which contains all the libraries info. It looks like that it can be generated by a site tool. To my codes review, there exist multiple records for a library for various versions in the above text file. And the codes check and compare a library record’s version info with the current version, and pick one matching a condition. There is no record with 'cxxstd' field at the text file for beta website but for main site. Unfortunately, there is no one to match version comparison condition for main site as well at the moment. The updates codes of beta website will only show 'C++ standard minimum level' with 'cxxstd' value only if a 'cxxstd' value exists.

2 1

Potential order statistic tree?
by Soronel Haetir 29 Dec '20

29 Dec '20

Boost developers, Would there be interest in adding an order statistic tree to the boost library? That is, a tree that instead of being sorted simply keeps nodes in whatever order is specified, along with a (potentially multi-index) per-node value and a total of per-node values of each node and its left-descent tree. I currently have two such types, a very capable intrusive version (not based on boost::intrusive though using some of the same ideas) and a less capable non-intrusive form that uses the mechanics of the intrusive form as an implementation detail. The reason for not being based on Boost.Intrusive is that the tree algorithms that Boost.Intrusive provides are all for search trees and this very definitely is not, plus the need to alter node weights during insert, delete and rotations and the Boost.Intrusive algorithm providers not having a good place to add that behavior. I have personally found this type very useful while implementing a rope container and also while implementing tracking for various parts of a text editor (that is, paragraph, line and run positions) (in terms of characters, graphemes and screen height). Perhaps the major drawback to what I have is that I have not been careful to isolate c++-version dependent code. Although I know it does compile with the latest msvc 2019 as well as the clang 10.0 that MS ships. I am simply not sure whether such a type has a broad enough appeal to make the work of adding it to boost worthwhile. -- Soronel Haetir soronel.haetir(a)gmail.com

4 3

Boost website changes and .'cxxstd'
by Edward Diener 24 Dec '20

24 Dec '20

Even though I have worked a little with PHP in the past I do not have the talent to make the change to the website which would incorporate the addition of the meta information json field 'cxxstd' to the Boost documentation web page for each library. The idea is that if 'cxxstd' is set to a value the documentation for that library would also show: C++ standard minimum level: C++nn where nn would be 11, 14, 17, or 20 depending on the value of 'cxxstd'. Alternatively if there is no 'cxxstd' entry for a library or if the value of 'cxxstd' is '03', we could either specify 'nn' as '03' or leave off the line stating the 'C++ standard minimum level completely. On the face of it this should be doable in the website code but evidently Daniel James is the only one who really understands how this works in the code and he is no longer active in Boost. So if someone else who understands the website code and PHP could do this it would be appreciated, since I think it will be valuable telling end-users whether a Boost library is usable at the C++ compiler level they are using.

3 3

(no subject)
by Harsh 21 Dec '20

21 Dec '20

Respected Sir/Madam Myself Harsh Agarwal a highly interested candidate to work on with ublas as a open source contributor but at starting need some guidance-: 1-:How can i start on with it. 2-: As if i want to participate in Gsoc 2021 till when will i get competency test. 3-: can i know about the basic project idea that will be for gsoc 2021 thanking you Harsh Agarwal 21/12/2020

2 1

regarding boost gsoc competency test 2021
by Mohd Huzaifa 20 Dec '20

20 Dec '20

hii sir/madam I want to ask about the boost competency test for gsoc 2021. When it will be available. And can I get the list of past competency tests.

2 1

Tagging the minimum C++ standard level for Boost libs
by Edward Diener 19 Dec '20

19 Dec '20

I had previously proposed that we tag the minimum C++ standard level for Boost libs by adding information to the json meta information in libraries.json for each library. I would like to revisit that proposal, which involved more elaborate suggestions, with this simpler overall proposal: for each Boost C++ library whose minimum C++ standard level is C++11 or above we add a json field called 'cxxstd' whose value corresponds to one of the same values as currently exists in Boost.Build for the 'cxxstd' feature, ie. 11,14,17,20, to the libraries.json file for that library. This json value can then be used in Boost documentation of each library to specify the minimum C++ standard level needed by an end-user in order to use that library. Obviously we can also add "cxxstd": "03" for the many Boost libraries which can still be used at the C++98/C++03 compilation level also, even though I would argue that not having a "cxxstd" json field should mean C++98/C++03 by default. I would be willing to create the necessary PRs for each library, as I have a pretty good internal list of this information. The gist of this proposal is to make it much easier for end-users wishing to use a Boost library to immediately know whether the library they wish to use is usable at the C++ standard compilation level they are using for compilation, without having to spend time searching for such information, which is often not readily available, in the documentation of the library they are considering. I can go ahead and start doing this now, but of course I am willing to listen to what others think about this. But let's not let another round of inertia stop doing at all what should be a simple means of telling end-user's whether a Boost library is at least minimally usable by them in their C++ projects.

5 13

Re: [boost] [release] Boost 1.75.0 Release Candidate 1
by Glen Fernandes 17 Dec '20

17 Dec '20

On 2020-12-13 03:34:00 Glen Fernandes wrote: > > On Sat, Dec 12, 2020 at 8:16 PM Edward Diener wrote: >> The final issue was that the index.html for the release showed 1.74 >> rather than 1.75. This seems to be generated from some sort of template >> where '{{version}}' is supposed to be plugged in by the correct version, >> but evidently did not work properly. Maybe someone who knows how this is >> supposed to work, but evidently did not, can look at it. > > Sounds like generate.php?page=index.html&version=<version> was invoked > with the wrong <version> . I'll take a look and see what I can find. Fixed: https://github.com/boostorg/release-tools/commit/b08dbc34451e9f5b09ec44cab5… Glen

1 0

Boost Pub/Sub message service model Implementation
by Rakshita Parihar 15 Dec '20

15 Dec '20

Hello, Currently, I am working on an IoT project where I need to send data from client to server. To transfer data, I need to setup a Pub/Sub message service model. Presently, I am using MQTT Paho C libraries to transmit data to server over TCP IP protocol but I want to switch to boost C++ library for the publish/subscribe model. I am a newbie to this library and have some queries: *1) Is there any boost C++ library for pub/sub model? If yes, please give me the details or link for the tutorial.* *2) If no library is present, please tell me how to implement a message pub/sub <https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern> service to communicate using boost C++ library?* Please, help me to solve these issues. Thanks & Regards, Rakshita Parihar

5 5

[release] Boost 1.75.0 Release Candidate 1
by Marshall Clow 13 Dec '20

13 Dec '20

[release] Boost 1.75.0 Release Candidate 1 The first release candidates for the 1.75.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.75.0/source/> The SHA256 checksums are as follows: caf36d7c13b3d8ce62282a64a695113945a13b0f1796a45160726d04295f95ed boost_1_75_0_rc1.zip aeb26f80e80945e82ee93e5939baebdca47b9dee80a07d3144be1e1a6a66dd6a boost_1_75_0_rc1.tar.gz 953db31e016db7bb207f11432bef7df100516eeb746843fa0486a222e3fd49cb boost_1_75_0_rc1.tar.bz2 3a8b314871646e7404886736273c053278ba71b11347f72d4751411d65d6d1a5 boost_1_75_0_rc1.7z 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

6 11

bootstrap was broken since 1.74
by Neo Anderson 12 Dec '20

12 Dec '20

Hi List, I am a casual user of boost library. I usually build boost for use to build CodeBlocks IDE on Windows platform. But since version 1.74, I found that bootstrap.bat was broken. So I skipped 1.74 and stuck to the old version 1.73. Today I am happy to see that 1.75 was out and I thought this problem would have been fixed since it’s a small problem. But I am wrong. I think line 15 lacks command line parameter: call .\build.bat %1. After adding that %1, I successfully built b2 with bootstrap.cmd gcc. But when I run .\b2, I get very confusing error messages (which are the same ones in 1.74): C:\Build\src\boost_1_75_0>.\b2 Performing configuration checks - default address-model : 32-bit - default architecture : x86 Building the Boost C++ Libraries. - compiler supports SSE2 : yes - compiler supports SSE4.1 : yes - has synchronization.lib : yes - C++11 mutex : yes - has BCrypt API : yes - has stat::st_mtim : no - has stat::st_mtimensec : no - has stat::st_mtimespec : no - has stat::st_birthtim : no - has stat::st_birthtimensec : no - has stat::st_birthtimespec : no - has statx : no - has statx syscall : no - cxx11_auto_declarations : yes - cxx11_constexpr : yes - cxx11_defaulted_functions : yes - cxx11_final : yes - cxx11_hdr_mutex : yes - cxx11_hdr_tuple : yes - cxx11_lambdas : yes - cxx11_noexcept : yes - cxx11_nullptr : yes - cxx11_rvalue_references : yes - cxx11_template_aliases : yes - cxx11_thread_local : no - cxx11_variadic_templates : yes - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam. note: to suppress this message, pass "--without-graph_parallel" to bjam. - zlib : yes - bzip2 : no - lzma : no - zstd : yes - lzma : no - has_lzma_cputhreads builds : no - cxx11_alignas : yes - cxx11_decltype : yes - iconv (libc) : no - iconv (separate) : yes - icu : no - icu (lib64) : no - native atomic int32 supported : yes - has message compiler : no - native syslog supported : no - pthread supports robust mutexes : no - compiler supports SSSE3 : yes - compiler supports AVX2 : yes - gcc visibility : yes - long double support : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. - cxx11_static_assert : yes - std::fstream is moveable and swappable : yes - Has Large File Support : yes warning: No python installation configured and autoconfiguration note: failed. See http://www.boost.org/libs/python/doc/building.html note: for configuration instructions or pass --without-python to note: suppress this message and silently skip all Boost.Python targets - libbacktrace builds : no - addr2line builds : no - WinDbg builds : yes - WinDbgCached builds : no - BOOST_COMP_GNUC >= 4.3.0 : yes - zlib : yes (cached) - bzip2 : no (cached) - lzma : no (cached) - zstd : yes (cached) - compiler supports SSE2 : no - compiler supports SSE4.1 : no - has synchronization.lib : no - C++11 mutex : no - has BCrypt API : no - is Windows CE : no - has stat::st_mtim : no - has stat::st_mtimensec : no - has stat::st_mtimespec : no - has stat::st_birthtim : no - has stat::st_birthtimensec : no - has stat::st_birthtimespec : no - has statx : no - has statx syscall : no - cxx11_auto_declarations : no - cxx11_constexpr : no - cxx11_defaulted_functions : no - cxx11_final : no - cxx11_hdr_mutex : no - cxx11_hdr_tuple : no - cxx11_lambdas : no - cxx11_noexcept : no - cxx11_nullptr : no - cxx11_rvalue_references : no - cxx11_template_aliases : no - cxx11_thread_local : no - cxx11_variadic_templates : no - native atomic int32 supported : no - has message compiler : no - native syslog supported : no - pthread supports robust mutexes : no - has_icu builds : no - compiler supports SSSE3 : no - compiler supports AVX2 : no C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:609: in start-building from module targe ts error: Recursion in main target references error: the following target are being built currently: error: ./forward ./stage ./stage-proper libs/filesystem/build/stage libs/filesystem/build/stage-depe ndencies libs/log/build/stage libs/log/build/stage-dependencies libs/filesystem/build/stage C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:776: in class(a)main-target.generate from module object(main-target)@7282 C:/Build/src/boost_1_75_0/tools/boost_install\boost-install.jam:1176: in generate-dependencies from module boost-install C:/Build/src/boost_1_75_0/tools/build/src/kernel\modules.jam:107: in modules.call-in from module boo st-install C:/Build/src/boost_1_75_0/tools/build/src/util\indirect.jam:105: in indirect.call from module indire ct C:/Build/src/boost_1_75_0/tools/build/src/tools\generate.jam:59: in construct from module object(gen erated-target-class)@2809 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:1364: in class(a)basic-target.generate fro m module object(generated-target-class)@2809 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:812: in generate-really from module obje ct(main-target)@11221 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:784: in class(a)main-target.generate from module object(main-target)@11221 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:934: in targets.generate-from-reference from module targets C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:1277: in generate-dependencies from modu le object(alias-target-class)@2810 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:1334: in class(a)basic-target.generate fro m module object(alias-target-class)@2810 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:812: in generate-really from module obje ct(main-target)@11222 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:784: in class(a)main-target.generate from module object(main-target)@11222 C:/Build/src/boost_1_75_0/tools/boost_install\boost-install.jam:1176: in generate-dependencies from module boost-install C:/Build/src/boost_1_75_0/tools/build/src/kernel\modules.jam:107: in modules.call-in from module boo st-install C:/Build/src/boost_1_75_0/tools/build/src/util\indirect.jam:105: in indirect.call from module indire ct C:/Build/src/boost_1_75_0/tools/build/src/tools\generate.jam:59: in construct from module object(gen erated-target-class)@1817 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:1364: in class(a)basic-target.generate fro m module object(generated-target-class)@1817 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:812: in generate-really from module obje ct(main-target)@7281 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:784: in class(a)main-target.generate from module object(main-target)@7281 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:934: in targets.generate-from-reference from module targets C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:1277: in generate-dependencies from modu le object(alias-target-class)@1818 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:1334: in class(a)basic-target.generate fro m module object(alias-target-class)@1818 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:812: in generate-really from module obje ct(main-target)@7282 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:784: in class(a)main-target.generate from module object(main-target)@7282 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:934: in targets.generate-from-reference from module targets C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:1277: in generate-dependencies from modu le object(alias-target-class)@184 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:1334: in class(a)basic-target.generate fro m module object(alias-target-class)@184 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:812: in generate-really from module obje ct(main-target)@5196 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:784: in class(a)main-target.generate from module object(main-target)@5196 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:934: in targets.generate-from-reference from module targets C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:1277: in generate-dependencies from modu le object(top-level-target)@190 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:1334: in alias-target-class.generate fro m module object(top-level-target)@190 C:/Build/src/boost_1_75_0\boostcpp.jam:403: in build-multiple from module object(top-level-target)@1 90 C:/Build/src/boost_1_75_0\boostcpp.jam:393: in class(a)top-level-target.generate from module object(to p-level-target)@190 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:812: in generate-really from module obje ct(main-target)@5198 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:784: in class(a)main-target.generate from module object(main-target)@5198 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:934: in targets.generate-from-reference from module targets C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:1277: in generate-dependencies from modu le object(top-level-target)@191 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:1334: in alias-target-class.generate fro m module object(top-level-target)@191 C:/Build/src/boost_1_75_0\boostcpp.jam:403: in build-multiple from module object(top-level-target)@1 91 C:/Build/src/boost_1_75_0\boostcpp.jam:393: in class(a)top-level-target.generate from module object(to p-level-target)@191 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:812: in generate-really from module obje ct(main-target)@5199 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:784: in class(a)main-target.generate from module object(main-target)@5199 C:/Build/src/boost_1_75_0/tools/build/src/build\targets.jam:273: in class(a)project-target.generate fr om module object(project-target)@134 C:/Build/src/boost_1_75_0/tools/build/src\build-system.jam:797: in load from module build-system C:/Build/src/boost_1_75_0/tools/build/src/kernel\modules.jam:295: in import from module modules C:/Build/src/boost_1_75_0/tools/build/src/kernel/bootstrap.jam:139: in boost-build from module C:/Build/src/boost_1_75_0/boost-build.jam:17: in module scope from module

1 0

[release] Boost 1.75.0
by Marshall Clow 11 Dec '20

11 Dec '20

Release 1.54.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 contains 1 new library and numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.75.0> You can also download directly from: <https://dl.bintray.com/boostorg/release/1.75.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. Thanks, -- The Boost Release Team Marshall Clow, Glen Fernandes, Michael Caisse

2 1

[release] 1.76.0 open for merging
by Marshall Clow 11 Dec '20

11 Dec '20

The master branch is open for merging all stable changes from develop, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging does not require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html <http://www.boost.org/development/index.html> Release schedule explanation: https://github.com/boostorg/wiki/wiki/Releases%3A-Schedule <https://github.com/boostorg/wiki/wiki/Releases%3A-Schedule> Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices <http://svn.boost.org/trac/boost/wiki/ImprovingPractices> -- The Boost Release Team

2 1

The new Boost 17.0.0
by Antony Polukhin 10 Dec '20

10 Dec '20

Hi, == The problem. TL;DR: we are having huge troubles with usability and popularity! Quite a lot of companies forbid using Boost because: * it provides vocabulary types, that should be the same across the whole project (like shared_ptr, filesystem::path or optional). Otherwise it's hard to combine different APIs * it is huge, in consists of legacy on more than a half, with a lot of dependencies between libraries. This is extremely painful for big companies, because there's no efficient distributed build system. Each company invents it's own and/or tries to minimize headers by all means. New companies (startups) also avoid Boost: * "We are using C++17, we do not want legacy libraries with C++98 support" * Junior developers are confused by multiple vocabulary types. "Should we use boost::optional or std::optional?" * hard to upgrade, because symbols are not versioned ISO C++ WG21 community not willing to push prototypes into Boost. "We aim to establish "existing practice" and provide reference implementations so that Boost libraries are suitable for eventual standardization." - that's not really true any more. == The Solution TL;DR: we need a C++17 fork of Boost with close to 0 dependencies between libraries and namespace versioning. С++17 provides many vocabulary types, feature test macro and a bunch of features for variadic templates. All of that allows us to drop a lot of weight and fix majority of popularity and usability problems. Rule of a thumb should be: "If the C++17 provides that functionality - use the standard version". That approach would allow to loose a lot of weight, do not mess with vocabulary types and significantly reduce dependencies https://pdimov.github.io/boostdep-report/master/module-levels.html By levels: config 0 -> we probably would not need it any more assert 1 -> 0 core 2 -> 1 (or 0 if we merge it with asser) smart_ptr 4 -> 2 exception 5 -> 2 stacktrace 5 -> 2 intrusive 5 -> 2 outcome 6 -> 3 container 6 -> 3 gil 11 -> 2? context 16 -> 2? dll 17 -> 1 asio 18 -> 3? beast 19 -> 4? == The Path TL;DR: we should start the Boost17 now and ship it as we are ready. Old Boost should be still available. The new approach requires quite a lot of effort and not all the maintainers have enough time to do the migration. We should keep releasing the existing Boost, while migrating the libraries to the Boost17. The migration is not as hard as it seems. It took 2 or 3 days to make Boost.DLL work with either boost or std filesystem. It could be done in less than a day, if I do not have to support the Boost filesystem. == Action points 0) Discuss 1) Bury the idea, wait for a few years, goto 0); or make a boost17 repo with the same layout as the existing one, but without submodules 2) start the migration -- Best regards, Antony Polukhin

28 120

[release] Master branch now closed for 1.75.0 release
by Marshall Clow 09 Dec '20

09 Dec '20

3 5

qvm: return type for mixed scalar type vector operations
by Kai Szuttor 09 Dec '20

09 Dec '20

Hey all, concerning vector operations in boost qvm, is it possible to somehow specify the return type of a binary operator with mixed scalar input data, e.g. operator+(vec<double, 3>, vec<int, 3>) ? Could not find the customisation point to do this depending on the involved operation. Thanks in advance, Kai

2 2

Re: [boost] Boost Digest, Vol 6513, Issue 3
by Brian Wood 07 Dec '20

07 Dec '20

Peter Dimov writes: > Marshall Clow wrote: > > > I must concur with Ville here; I have had several people tell me they > won?t > > use Boost because ?it changes with every release?. > > Boost does change with every release, and I still keep using 1.38 in > several > projects of mine, but these changes are not limited to ABI at all. > Everything changes, you have to retest the whole lot, for correctness as > well as performance. > > And in general, expecting ABI stability from a collection of predominantly > header-only libraries is setting one up for severe disappointment. > > The standardized libraries are more header-only than Boost so am not sure how this isn't a rap on them also. Somehow C++ has become successful in spite of this. Brian Ebenezer Enterprises - In G-d we trust. https://github.com/Ebenezer-group/onwards

3 2

[SmartPtr] intrusive_ref_counter CounterPolicyT requirements API?
by Billy 05 Dec '20

05 Dec '20

Hi Boost, We're considering implementing our own atomic ref count for `intrusive_ref_count` [*]. A question came up. Is the `CounterPolicyT` template parameter a stable extension hook, or are users expected to strictly stick to the two provided policies of `thread_unsafe_counter` and `thread_safe_counter`? I can see that under the hood, these policy structs are trivially simple and we can just do it, but the question is really about whether the lack of documentation implies that it's a private boost detail. From https://www.boost.org/doc/libs/1_74_0/libs/smart_ptr/doc/html/smart_ptr.htm… "The second parameter is a policy that defines the nature of the reference counter. The library provides two such policies: thread_unsafe_counter and thread_safe_counter." Thanks for your time, Billy Donahue [*] Incidentally we want to increment with memory order relaxed instead of acq_rel. -- ǝnɥɐuop ʎllıq

3 4

CONTRIBUTION TOWARD YOUR OPEN SOURCE COMMUNITY.
by Prakash Choure 03 Dec '20

03 Dec '20

Hii sir/mam I am Prakash Choure and i want to contribute my skill to your open source organisation . As i am a beginner can you guide me for contribution toward your organization .My knowledge is "C" , "C++" And basic of Data structure and Algorithm . please can your team guide me. Thank you

3 2

[release] 1.75.0 post-beta merges
by Marshall Clow 02 Dec '20

02 Dec '20

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See <https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy> Reminder: The master branch closes for the release on December 2nd. Full calendar here: https://www.boost.org/development/ -- The release managers

10 47

PolyCollection
by Brian Wood 30 Nov '20

30 Nov '20

Shalom Hey, is anyone using PolyCollection? I have serialization support for it: https://github.com/Ebenezer-group/onwards/tree/master/example/poly If you considered it, but chose an alternative library, what was the reason? Thanks. Brian Ebenezer Enterprises - Enjoying programming again. https://webEbenezer.net

1 0

[release] Issues
by Glen Fernandes 30 Nov '20

30 Nov '20

Need resolution: * Boost.Utility's <boost/operators.hpp> and C++20 * Boost.uBLAS tests failing C++03 and C++14. (They were failing C++20 but I cherry-picked the allocator fixes from develop, so these pass now) Glen

2 1

Re: [boost] The new Boost 17.0.0
by Glen Fernandes 29 Nov '20

29 Nov '20

On 2020-11-29, Raffi Enficiaud wrote: > 0/ For the discussions I am all for it, but I would absolutely not try > to gather consensus. Because there won't be. You definitely don't need consensus. You are free to drop C++03 and C++11 and C++14 support from Boost.Test whenever you want. We've been steadily migrating Boost libraries away from using Boost.Test to using Boost.LightweightTest for various reasons. (And have plans to migrate a few more to Boost.LightweightTest by Boost 1.76) So you can decide to require C++17 or higher for Boost.Test and not have to worry about other Boost libraries. We'll make sure their tests are still working by moving them to LWT. Just give us some warning, before you drop any support. :) Glen

1 0

Re: [boost] The new Boost 17.0.0
by Glen Fernandes 27 Nov '20

27 Nov '20

Dominique Devienne wrote: > > Glen Fernandes wrote >> I would not be in favor of a Boost distribution that requires anything >> higher than C++11 for existing libraries. i.e. Not C++17 or even >> C++14. > > But that's basically Boost as it stands, i.e. Boost 1.x. > I don't think anyone's proposing to drop that. That's Boost 1.x with more C++11 and less C++03 - with authors who choose to drop C++03 support, requiring C++11 at a minimum as per: https://pdimov.github.io/articles/phasing_out_cxx03.html This is something which Boost authors are actually acting on. e.g. Boost.Math and Boost.Multiprecision as of a future Boost 1.77 release: https://www.boost.org/users/history/version_1_73_0.html <quote> Math * IMPORTANT: C++03 support is now deprecated and will be removed from March 2021. </quote> <quote> Multiprecision * IMPORTANT: C++03 support is now deprecated and will be removed from March 2021. </quote> i.e. This is promising because people support this particular proposal enough to do something, not just for the (potentially unlimited) joy of discussing it on a list. > But isn't this just a "teething" issue? I see Ville already replied in fact. I'm following this discussion over this in C++ committee EWG reflector. I'm optimistic that people will do the right thing by users. But I prefer to make decisions based on what I know now, and what has bitten users today, with -std=c++20 and GCC 10.1 that has already shipped, not speculation about what will happen. As I said before, this is just me. C++11 (not higher, not C++17 or C++20) is just what I support and what I'd be willing to put in work towards in existing Boost libraries (and even volunteer to do for those that I do not currently maintain, but would welcome the contributions). Other authors remain free to drop support for everything besides C++17 or C++20 if they want. Glen

1 1

Re: [boost] The new Boost 17.0.0
by Glen Fernandes 27 Nov '20

27 Nov '20

Speaking only for myself as an author of a Boost library, maintainer of many Boost libraries, and contributor to many Boost libraries, as well as being involved in the Boost release process: 1. Based on my personal knowledge of Boost users, as well as e-mails to the Boost developers lists (boost@...), and the Boost Owners lists (boost-owner@...) from users such as: - @us.af.mil (US Airforce) - @nasa.gov (NASA) and others I would not be in favor of a Boost distribution that requires anything higher than C++11 for existing libraries. i.e. Not C++17 or even C++14. 2. Based on first hand accounts of certain users choosing not to migrate to C++20 because of a silently breaking change in the language affecting their code (operator== rewriting rules, which has even broken certain Boost libraries like Rational), I would certainly not be in favor of changing existing Boost libraries to require C++20 for anything in an official Boost distribution. Glen

4 3

Re: [boost] [release] 1.75.0 post-beta merges
by Peter Dimov 26 Nov '20

26 Nov '20

>>>> ...failed testing.capture-output >>>> ..\..\bin.v2\libs\filesystem\test\operations_unit_test.test\clang-win-10.0.0\release\threading-multi\operations_unit_test.run... ... > This looks like a Clang x86 codegen bug. The compiler returns the > `file_status` from `get_status` on the stack and then overwrites it with > `push` instructions for some reason. > > Not the first x86 clang-cl problem. I'll upgrade from 10.0 to 11.0 to see > if it's fixed. Still not fixed in 11.0.

2 3

[random] Merging to master for 1.75 release
by Edward Diener 25 Nov '20

25 Nov '20

Is there any possibility of merging 'develop' to 'master' for the random library for the 1.75 release ? The 'master' branch has not been updated for 2 years, or since the 1.70 release. While I am not claiming all invaluable fixes I know my fix for Embarcadero C++ clang-based support and another fix for correctly auto-linking random_device is among the 'develop' branch fixes which have never made it to the 'master' branch.

4 9

Submitting release notes
by Andrzej Krzemienski 25 Nov '20

25 Nov '20

I am sorry for this silly question, but can someone remind me, where we file PR-s with library release notes? Can someone point me to the place where this is documented? Regards, &rzej;

2 1

[leaf] Request to merge bug fix to master for 1.75 release
by Emil Dotchevski 24 Nov '20

24 Nov '20

I'm requesting permission to merge a bug fix by vector-of-bool in LEAF which makes it work correctly with std::system_error: https://github.com/boostorg/leaf/pull/15/commits/efc56d1c703777fea4fef2bd24… (There is a minor related change on top of this PR, but this bug fix is the important change in behavior. Note that LEAF is a new library in 1.75).

2 1

[release] Boost 1.75.0 Beta 1 Release Candidate 2
by Marshall Clow 17 Nov '20

17 Nov '20

The second release candidates for the 1.75.0 beta release are now available at: <https://dl.bintray.com/boostorg/beta/1.75.0.beta1/source/> The SHA256 checksums are as follows: 3f01d3e5dc822e151892040d4667e364ea808d208d2e49cc7a1802bd4da3d4cc boost_1_75_0_b1_rc2.7z 9b75a80f845d4ae312e3c9151ffdfe3fed450973095e0a15c68d0be394f2f2df boost_1_75_0_b1_rc2.tar.bz2 123519d4b056fbbd69e452db880abe2c7e55f21779d44a4d6b6c714d5c13c3ee boost_1_75_0_b1_rc2.tar.gz b73e01d22d5b3d2ff82f14a371e3974fab30448bf6ff5ac8b9c829539a19c2d7 boost_1_75_0_b1_rc2.zip 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

9 23

[release] Fixing Boost.Rational and boost/operators.hpp infinite loop in C++20 by 1.75
by Glen Fernandes 16 Nov '20

16 Nov '20

We have a problem with Boost.Rational and <boost/operators.hpp> in Boost.Utility in C++20 standards mode. I've fixed Boost.Rational in develop. Relevant GitHub issues: 1. https://github.com/boostorg/rational/issues/43 2. https://github.com/boostorg/utility/issues/65 My fix for Boost.Rational that I will merge to master for the 1.75 release: https://github.com/boostorg/rational/pull/45 The root cause is the same. C++20 adds new language rules that implicitly generate some operators, and the current implementations result in an infinite loop. (In both cases an equality operator ends up calling itself recursively). GCC does emit a warning diagnostic in C++20 mode, but as usual these tend to be unnoticed at build time. ../../boost/rational.hpp:779:16: warning: in C++20 this comparison calls the current function recursively with reversed arguments 779 | return a == b; | ~~^~~~ So this issue was found by three independent users of Rational (one who reported a Github issue, the other who complained on Reddit, and a third that tried running the Rational unit tests with GCC10 and found two failures). <boost/operators.hpp> in Boost.Utility still needs a fix for C++20 mode, but it has an active maintainer unlike Rational. The GitHub issue for it was closed (I've reopened it) because it was assumed to be a defect in the standard and one that vendors would fix. We did have some discussion on the C++ standard committee reflector about this, however - whatever the future change to the standard is - GCC and Clang with -std=c++20 that implement these rules have already been released and users are using it, so we should fix this in Boost 1.75. Glen

2 1

Re: [boost] [release] 1.75.0 post-beta merges
by Glen Fernandes 16 Nov '20

16 Nov '20

Robert Ramey wrote: > request permission to sync changes in develop into master for > two libraries: serialization and safe_numerics. They've been ready for > some time, I just forgot to do it in time. Go ahead. Glen

1 0

[release] Boost 1.74.0 beta 1 released
by Marshall Clow 14 Nov '20

14 Nov '20

Boost release 1.75.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.75.0.beta1/source/> The SHA256 checksums are as follows: 3f01d3e5dc822e151892040d4667e364ea808d208d2e49cc7a1802bd4da3d4cc boost_1_75_0_b1.7z 9b75a80f845d4ae312e3c9151ffdfe3fed450973095e0a15c68d0be394f2f2df boost_1_75_0_b1.tar.bz2 123519d4b056fbbd69e452db880abe2c7e55f21779d44a4d6b6c714d5c13c3ee boost_1_75_0_b1.tar.gz b73e01d22d5b3d2ff82f14a371e3974fab30448bf6ff5ac8b9c829539a19c2d7 boost_1_75_0_b1.zip For details of what's in the release, see <https://www.boost.org/users/history/version_1_75_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

1 0

Boost.Exception regression in 1.75.0 beta 1
by Niall Douglas 14 Nov '20

14 Nov '20

If you diagnose the test failures (which are present across all compilers) in https://www.boost.org/development/tests/develop/developer/outcome.html which report failures of the form: ``` unknown location(0): fatal error: in "works_outcome": Throw location unknown (consider using BOOST_THROW_EXCEPTION) Dynamic exception type: struct boost::wrapexcept<class boost::exception_ptr> libs\outcome\test\tests\core-outcome.cpp(173): last checkpoint *** 1 failure is detected in the test module "Outcome" ``` The cause is test code such as: ``` boost::system::error_code ec(5, boost::system::system_category()); auto e = boost::copy_exception(boost::system::system_error(ec)); // NOLINT outcome<int> m(e); BOOST_CHECK_THROW(m.value(), boost::system::system_error); ``` Outcome calls boost::rethrow_exception() to rethrow the exception_ptr. boost::rethrow_exception() is not rethrowing the boost::system::system_error held within the boost::exception_ptr. It is throwing instead boost::wrapexcept<class boost::exception_ptr>. This causes BOOST_CHECK_THROW() to not correctly trap the type of exception thrown, and thus the test fails. boost::wrapexcept<E> inherits from E. It seems to me therefore that catching a const E& ought to catch throws of boost::wrapexcept<E>, and therefore this code is correct. I double checked this at https://wandbox.org/permlink/n9Wjb5cPpfHEFalp, and indeed it works as expected. However, obviously enough this is failing, and it was not failing in Boost 1.74, so this is a regression. I am stumped as to the exact cause. This affects all platforms, POSIX, Windows, clang, GCC and MSVC. Niall

3 2

permission to merge fix
by Oliver Kowalke 08 Nov '20

08 Nov '20

Do I get permission to merge a fix related to boostorg/fiber#264 <https://github.com/boostorg/fiber/issues/264> into master? Oliver

3 3

[release] Boost 1.75.0 Beta 1 Release Candidate 1
by Marshall Clow 07 Nov '20

07 Nov '20

The first release candidates for the 1.75.0 beta release are now available at: <https://dl.bintray.com/boostorg/release/1.75.0.beta1/source/> The SHA256 checksums are as follows: c271f488c7c8de7c147bf8675d578fb2f06c6c171d9547c5a40cddccb9f2a6c4 boost_1_75_0_b1_rc1.7z 0db0944e9d2250907e011900eea304ca055d1c418d38b3fbb1eee692a6b851a6 boost_1_75_0_b1_rc1.tar.bz2 624bd6b03d86bf1387b4e8927dab16b4198f255f15dd71d6a8c1c5ec270584b3 boost_1_75_0_b1_rc1.tar.gz 07ddca7c39ea9152bad73bee4f10f2c9c8e3a2d7e153aa945a343f83eca5db59 boost_1_75_0_b1_rc1.zip 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

3 6

[1.75 release] Merging 'develop' to 'master' for Embarcadero fix
by Edward Diener 06 Nov '20

06 Nov '20

A number of libraries have my PR to enable Embarcadero C++ clang-based compilers for Boost in their 'develop' branch but the branch has not been merged to 'master' for the 1.75 release. In the large majority of cases my PR for Embarcadero is the only difference between 'develop' and 'master'. These libraries are: assign circular_buffer container_hash date_time foreach graph iostreams numeric_conversion optional pool ptr_container random static_assert thread typeof units unordered If any of the maintainers of these libraries could see fit to get my PR in 'master' from 'develop' for the 1.75 release, it would be appreciated. I can assert that the PR causes no problems in the 'develop' regression tests for the aforementioned libraries. I have also opened up an issue for each of the aforementioned libraries in their Github page regarding my request.

7 18

[release] Master branch now closed for 1.75.0 beta release
by Marshall Clow 06 Nov '20

06 Nov '20

Please do not make any commits to the master branch.

1 0

1.75 schedule reminder
by Peter Dimov 03 Nov '20

03 Nov '20

A reminder that Oct 21 was the cutoff date for new library additions, and the upcoming deadlines are - Oct 28: Boost 1.75.0 closed for major changes - Nov 4: Boost 1.75.0 closed for beta - Nov 11: Boost 1.75.0 beta - Dec 2: Boost 1.75.0 closed for release - Dec 9: Boost 1.75.0 release (See the calendar at https://www.boost.org/development/index.html.)

5 4

sticky question regarding boost rational
by Robert Ramey 02 Nov '20

02 Nov '20

boost rational is tripping up one of my examples in safe numerics: // solution: use safe integer in rational definition using safe_rational = boost::rational< boost::safe_numerics::safe<int> >; // use rationals created with safe_t const safe_rational sc {1, std::numeric_limits<int>::max()}; std::cout << "c = " << sc << std::endl; const safe_rational sd {1, 2}; std::cout << "d = " << sd << std::endl; std::cout << "c * d = "; try { // multiply them. This will overflow std::cout << sc * sd << std::endl; // use of overload operator * is ambiguous. rational.hpp contains - among other things, the following definitions for the * operator: template <class IntType, class Arg> BOOST_CXX14_CONSTEXPR inline typename boost::enable_if_c < rational_detail::is_compatible_integer<Arg, IntType>::value || is_same<rational<IntType>, Arg>::value, rational<IntType> >::type operator * (const rational<IntType>& a, const Arg& b) { rational<IntType> t(a); return t *= b; } template <class Arg, class IntType> BOOST_CXX14_CONSTEXPR inline typename boost::enable_if_c < rational_detail::is_compatible_integer<Arg, IntType>::value, rational<IntType> >::type operator * (const Arg& b, const rational<IntType>& a) { rational<IntType> t(a); return t *= b; } Soooooo - it seems that sc * sd will match both of the above definitions. Its unclear what the purpose of these two different overloads are. They look pretty similar to me. the definition for is_compatible_integer. namespace rational_detail{ template <class FromInt, class ToInt, typename Enable = void> struct is_compatible_integer; template <class FromInt, class ToInt> struct is_compatible_integer<FromInt, ToInt, typename enable_if_c<!is_array<FromInt>::value>::type> { BOOST_STATIC_CONSTANT(bool, value = ((std::numeric_limits<FromInt>::is_specialized && std::numeric_limits<FromInt>::is_integer && (std::numeric_limits<FromInt>::digits <=std::numeric_limits<ToInt>::digits) && (std::numeric_limits<FromInt>::radix == std::numeric_limits<ToInt>::radix) && ((std::numeric_limits<FromInt>::is_signed == false) || (std::numeric_limits<ToInt>::is_signed == true)) && is_convertible<FromInt, ToInt>::value) || is_same<FromInt, ToInt>::value) || (is_class<ToInt>::value && is_class<FromInt>::value && is_convertible<FromInt, ToInt>::value)); }; ... In fact, since it looks like if FromInt and ToInt are the same types (as they are in my case, one will always got more than one match. Is anyone (John Maddock - where are you?) able to shed some light on this for me? Robert Ramey

2 1

[release] Reminder: Master branch closes for the 1.75.0 beta THIS WEDNESDAY
by Marshall Clow 02 Nov '20

02 Nov '20

See the calendar here for more dates: https://www.boost.org/development/ <https://www.boost.org/development/> The master branch will be re-opened after the beta release. Thanks, — The Boost Release Team

1 0

Compile failure in boost.signals2 with latest clang, c++20 and libc++
by Richard Hodges 31 Oct '20

31 Oct '20

Details in the linked issue: https://github.com/boostorg/signals2/issues/46 -- Richard Hodges

1 0

[Algorithm] Implementing: Find Longest Palindromic Substring(Sub-vector).
by Kanishk 31 Oct '20

31 Oct '20

Hello all, I'm new to the Boost community and this is my first time posting to the mailing group. What brought me here: I'm a Computer Science student and I often have to code up string/sequence related algorithms. An algorithm that I found was missing from the boost libraries was "Find Longest Palindromic Substring(or generic Sub-vector)". Boost has *is_palindrome *( https://www.boost.org/doc/libs/1_66_0/boost/algorithm/is_palindrome.hpp) but using that to check every possible substring will result in an O(N^3) runtime. It is trivial to implement an O(N^2) algorithm for this purpose using dynamic-programming. It is also possible to implement this in O(N) using the Manacher's algorithm ( https://en.wikipedia.org/wiki/Longest_palindromic_substring#Manacher's_algorithm ). Will this be a useful addition to the Boost.Algorithm library? If so, I would love to start contributing to boost through this. Regards, Kanishk

1 0

[histogram][type_traits] strange compile error in boost.histogram for gcc-7.1+ with -std=c++17; possible bug in gcc?
by Hans Dembinski 30 Oct '20

30 Oct '20

Dear John and the other gurus, a strange bug was reported for Boost.Histogram. It is a difficult one for which I would like to ask for help. To me it looks like a bug in gcc. Here is the issue: https://github.com/boostorg/histogram/issues/290 And here is a link to reproduce it: https://godbolt.org/z/oK4866 The following innocent code compiled with gcc-7.1 or newer with -std=c++17 ``` #include <boost/type_traits/rank.hpp> #include <boost/histogram/axis/traits.hpp> int main() { return 0; } ``` produces this error message (excerpt): ``` cc1plus: error: return type specified for deduction guide In file included from <source>:2: /celibs/boost_1_74_0/boost/histogram/axis/traits.hpp:411:11: error: 'decl-specifier' in declaration of deduction guide 411 | constexpr unsigned rank(const Axis& axis) { | ^~~~~~~~ /celibs/boost_1_74_0/boost/histogram/axis/traits.hpp:411:1: error: 'decl-specifier' in declaration of deduction guide 411 | constexpr unsigned rank(const Axis& axis) { | ^~~~~~~~~ /celibs/boost_1_74_0/boost/histogram/axis/traits.hpp:411:11: error: 'unsigned' specified with 'rank<...auto...>' 411 | constexpr unsigned rank(const Axis& axis) { | ^~~~~~~~ /celibs/boost_1_74_0/boost/histogram/axis/traits.hpp:411:20: error: deduction guide for 'boost::rank<T>' must have trailing return type 411 | constexpr unsigned rank(const Axis& axis) { | ^~~~ In file included from <source>:1: /celibs/boost_1_74_0/boost/type_traits/rank.hpp:82:27: note: 'template<class T> struct boost::rank' declared here 82 | template <class T> struct rank : public integral_constant<std::size_t, (::boost::detail::rank_imp<T, 0>::value)>{}; | ^~~~ ``` gcc interprets my function called `rank` as a deduction guide for `boost::rank` in boost/type_traits/rank.hpp. It then continues to complain that this function does not look like a deduction guide. Well, it isn't one, duh. I can see nothing wrong with my code or the code in boost/type_traits, so my guess is a bug in gcc. If you all agree, I would report this. If this is really a bug in gcc, however, it exists since v7.1 all the way to gcc trunk. In either case, it would be great if we could use a workaround in Boost until that problem is fixed. I found a workaround is to replace line 82 in boost/type_traits/rank.hpp with: ``` template <class T> using rank = integral_constant<std::size_t, (::boost::detail::rank_imp<T, 0>::value)>; ``` This avoids the issue because now the struct ``rank`` is gone and therefore gcc does not try to find a deduction guide for it. Is there a better solution? Best regards, Hans

3 4

[gil] Phasing out support C++11 and switching to C++17
by Mateusz Loskot 27 Oct '20

27 Oct '20

Hi, We're discussing [1] to start switching GIL to C++17 in the near future and, following Peter Dimov's policy on phasing out C++XY support [2], we'd like to: 1. Declare C++11 support deprecated in 1.75 (December 2020) 2. Drop C++11 support in 1.77 (?) (August 2021) Could anyone help us validate and confirm that it's a good plan or are we overlooking any policies from Boost's release perspective? [1] https://lists.boost.org/boost-gil/2020/10/0465.php [2] https://pdimov.github.io/articles/phasing_out_cxx03.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

7 18

[pfr] Ready for informal mini review
by Antony Polukhin 20 Oct '20

20 Oct '20

Hi, Issues noted during the review period were fixed. Mainly: * global_ops.hpp is removed * boost::pfr::ops::operator* were changed to functions and moved to boost::pfr:: namespace * Flat reflection was purged * Big rewrite of docs I'd appreciate a look at the updated library https://github.com/boostorg/pfr and its docs https://apolukhin.github.io/magic_get/index.html Any comments and feedback is welcomed! -- Best regards, Antony Polukhin

2 3

Re: [boost] [pfr] Ready for informal mini review
by Glen Fernandes 20 Oct '20

20 Oct '20

Antony Polukhin wrote: > I'd appreciate a look at the updated library > > https://github.com/boostorg/pfr and its docs > https://apolukhin.github.io/magic_get/index.html > > Any comments and feedback is welcomed! Note that the last day for new libraries for Boost 1.75 is tomorrow (2020-10-21). PFR has a develop submodule, but no master submodule yet. I was waiting until you believe it is ready, and have ironed out all the issues on develop. If you want it included in the 1.75 release, and there are no objections from any reviewers, I can add the master submodule today. (It was already added to the in-progress release notes for 1.75, but that can be removed if you don't want to release it until 1.76). Glen

2 2

[FPR] Review of FPR starts Today: Sept 28 - Oct 7
by Benedek Thaler 16 Oct '20

16 Oct '20

The Boost formal review of the FPR (Flat Precise Reflection, ex Magic Get, ex PODs Flat Reflection) starts Today, taking place from September 28, 2020 to October 7, 2020. The library is authored by Antony Polukhin, author of Boost.DLL, Stacktrace, Type Index libraries. Documentation: http://apolukhin.github.io/magic_get/ Source: https://github.com/apolukhin/magic_get The library is meant for accessing structure elements by index and providing other std::tuple like methods for user defined types without any macro or boilerplate code. The FPR documentation summarizes the out-of-the-box added functionality for aggregate initializable structures: - comparison operators - heterogeneous comparators - hash - stream operators - access to members by index - member reflections - methods for cooperation with std::tuple - methods to visit each field of the structure If the description isn't immediately obvious for you, here's a motivating example: // requires: C++14 #include <iostream> #include <string> #include "boost/pfr/precise.hpp" struct some_person { std::string name; unsigned birth_year; }; int main() { some_person val{"Edgar Allan Poe", 1809}; std::cout << boost::pfr::get<0>(val) // No macro! << " was born in " << boost::pfr::get<1>(val); // Works with any aggregate initializables! } Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including FPR 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 Thank you for your effort in the Boost community. Benedek - review manager of the FPR library

8 12

Latest boost documentation
by Raghu Huchchannavar 15 Oct '20

15 Oct '20

Hi, Can anyone help me in getting the latest boost documentation either a link or the pdf one. -- Regards Raghavendra Huchchannavar.

3 2

boost::asio::deadline_timer segmentation in version 1.71
by Jupiter 14 Oct '20

14 Oct '20

Hi, My application is running one thread under boost::asio::io_service, it is an embedded system running on an ARM processor with Linux, so no gdb installed. The application is also using a boost::asio::deadline_timer to call a function every second, but I got following segmentation stack trace: _ZN5boost4asio6detail9scheduler10do_run_oneERNS1_27conditionally_enabled_mutex11scoped_lockERNS1_21scheduler_thread_infoERKNS_6system10error_codeE+0xdd _ZN5boost4asio6detail9scheduler3runERNS_6system10error_codeE+0x83 I thought I could run c++filt to demangling the library name, not sure why it didn't demangle the name today. I used the same boost::asio::deadline_timer version 1.69 for another application running on Ubuntu which was working fine, what I could be missing? Thank you. Kind regards, Jupiter

2 2

[PFR][review] Result
by Benedek Thaler 10 Oct '20

10 Oct '20

Thanks to all of you who participated in the formal review of PFR, henceforth known as Boost.PFR, and Antony Polukhin for submitting this magical library. PFR is ACCEPTed into Boost, with the following results: ACCEPT: 5 votes CONDITIONAL ACCEPT: 1 vote REJECT: 0 votes Reviewers highlighted that the library is "very useful", "magical" and "provides a form of reflection in a simpler manner than other solutions thus far". During the review, several points of improvements were identified, and Antony committed to improve the library accordingly. The main concerns were: - Definition of the type concept the library can work with - Clarification of the flat / precise use-cases - The presence of global operators - The way output formatting is defined - Dropping "Reflection" from the name (this is already reflected in the docs) Antony plans to: - Remove Flat reflection - Remove global_ops - Add more examples to the docs, introduce terms in a cleaner manner - Improve the reference section - Take another look at the pfr::ops and macro for operators After all these changes have been implemented, Antony would really like to have a mini-review, regardless that the library is already ACCEPTed, further confirming his high standards. Good luck Antony, keep up the good work! Benedek review wizard

7 15

[PFR][review] Review of PFR ends Today
by Benedek Thaler 07 Oct '20

07 Oct '20

The review of the PFR: Precise and Flat tuple Representation (ex Precise and Flat Reflection, ex Magic Get, ex PODs Flat Reflection) ends Today. Do not hesitate to send late reviews, there's still time. Documentation: http://apolukhin.github.io/magic_get/ Source: https://github.com/apolukhin/magic_get I'll announce the review results soon. Benedek review manager

2 1

[PFR][review] Andrzej's review
by Andrzej Krzemienski 07 Oct '20

07 Oct '20

Hi Everyone, This is my partial review of PFR library. I have read the docs, watched Antony's talk, played with some toy examples, and had a brief look at the implementation of pfr::tuple_size. I spent like 14 hours in total on this. I have studied the subject of tuple-like access to class objects a while back, which resulted in this proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3326.pdf. I like the library, I think it has the potential to address a small but a well understood demand. While I would like to see it included in Boost, I believe it should not be accepted just yet, in its current shape. I disagree with parts of the design (injecting the interface of user types) as explained below. Missing documentation parts (I mean the concept "Baseless Aggregate") is also an issue for me. First, it might be an indication of a flaw in the design. Second, it might cover some bugs in the implementation. Third, making another review with updated docs might attract more reviews and may make people appreciate the library more. Alternatively, I could have called it a conditional acceptance with everything listed below as conditions. Since reviewers are not casting votes but give recommendations instead, the Review Manager may want to take this into account. I think that this type of the library is mostly about the documentation and design (like, the scope). The implementation will necessarily be a number of hacks to provide the magic. Since I question parts of the design, I didn't find it necessary to review the implementation in detail. The following list may appear long, and look like a long list of complaints, so I need to make this clear up front. I really like the library, and I intend to use it next time I have a need for the tuple-like access to PODs, even download it from GitHub. I recommend the rejection because I see the second review as an opportunity for the library to become even better. DOCUMENTATION Documentation does explain how to use the library, and after a while it becomes easy to use every function, at least the functions that I tried. But it is missing some important parts, therefore it confuses the potential users as to what its scope is, and gives an (false) impression that it is defective. (Some of the below points may not hold anymore, as I have noticed the documentation has changed during the review period.) 1. The library name is misleading. It uses the name "reflection" but it doesn't really implement reflection. A reflection would be a way of querying the system for different properties of declarations in the program. This is not the case here. 2. The intro page misses the opportunity to present the scope of the library, its power, and the minimal example of how to use it and how it makes the life of the programmer easier. It is a very good library, and it would be a great loss if it was overlooked due to not being advertised effectively. I volunteer to provide the content of the initial page that I believe would meet the criteria. 3. The library buds on a basic concept of "Base-less aggregate". It must document it up front. And if possible try to statically detect if the types satisfy it to the extent that this is doable. After reading the docs, the user has to have a clear picture which types will and which won't work with the library. 4. It should contain a couple of motivating use cases, both for flat and precise representation. It is not enough to show how they work. The user must also see why they would be useful for anyone. Some users immediately see that this library addresses their use, others are confused, and cannot see any purpose in having it. 5. One use case for flat reflection is when a couple of aggregates have a common subset: ``` struct Person { std::string firstName; std::string lastName; int age; }; struct Employee { Person person; double salary; }; struct Prisoner { Person person int cellNumber; }; std::set<Person, boost::pfr::flat_less<>>; std::set<Employee , boost::pfr::flat_less<>>; std::set<Prisoner , boost::pfr::flat_less<>>; ``` Just saying, "use flat variants when you want to flatten your aggregate" is not enough to make the user see the capabilities of this library. I think that this use case should be documented. 6. I believe that individual operations are underspecified. For instance: i. pfr::write (http://apolukhin.github.io/magic_get/boost/pfr/write.html) has a section "Description", but it doesn't say what the function is doing. To some extent, we can guess that from the signature but some important questions remain unanswered: What format of the serialized output does the library guarantee? Does it guarantee any format at all? Do you leave yourself a freedom to change it in the future without notice? Can users customize it? If so, where is it specified? (This would be a no-problem if the library didn't provide stream insertion operations.) ii. The library says it can inject relational operators (and others) but it doesn't specify what their semantics are. 7. The means of specifying the semantics of the functions could be improved (i.e., made shorter and more precise) if you specified prf::structure_to_tuple (and pfr::flat_structure_to_tuple) very precisely as std::tie() on the corresponding aggregate elements, and then define the semantics of every other function in terms of prf::structure_to_tuple. Instead, I can see that prf::structure_to_tuple is underspecified ( http://apolukhin.github.io/magic_get/boost/pfr/structure_to_tuple.html) Section "Description" does not describe what the function is doing. DESIGN 1. I am missing the concept "Base-less aggregate" that is a basic building block of this library. I would expect it to appear in one of the front pages of the docs, and static checks in the code that would mention this name, so that I am immediately informed if I fail to satisfy the concept. I realize that defining a type trait for this is impossible, but even if it is a line of code deep inside the implementation that breaks (like, decomposing the aggregate into a structure binding), this line should have a comment saying something like "if compilation breaks on this line, it is likely because your type does not satisfy the requirements of a BaselessAggregate." 2. I appreciate functions that this library defines in namespace boost::pfr, such as pfr::less or pfr::for_each_field or pfr::structure_to_tuple; but I do not appreciate that this library injects functions into global namespace or my namespace or even that it provides operators (like <<, which are naturally part of my classes' interface) for my types in namespace boost::pfr. I really consider this harmful, causing subtle ADL-related bugs. If I want my types logged, I would rather expect to be able to type: ``` // in my namespace inline std::ostream& operator<<(std::ostream& o, MyAggregate const& a) { return boost::fpr::write(o, a); } ``` Same with relational operators: rather than library injecting them (and potentially causing ADL problems or ODR violations, especially in C++20), I would rather use a named PFR function where needed: ``` sort(myAggregates.begin(), myAggregates.end(), boost::fpr::less<>{}); std::set<MyAggregate, boost::fpr::less<>> map; ``` This is a bit more verbose, but: i. Still does not require me to list members anywhere (the primary advantage of this library). ii. There is no possibility of getting any ADL- or ODR-related bug. The ODR-violation bugs are really nasty. You do everything fine in your .cpp file and you have no clue why the program desn't work as you expect. And this is because someone else in another .cpp file has put different declarations. And if you have 100.000 cpp files, you may not be able to find the cause for weeks. Offering these operators encourages this type of bugs. 3. If we eliminate the injected operators from the picture, we get a sound interface that can be reused in the future revisions of C++, where the internals will be able to use native C++26 reflection instead of the current hacks. We would get the beautiful effect that the initial Boost libraries provided: an interface that can work uniformly both with old and modern versions of C++. 4. There is another reason why I do not like the stream insertion operators. They just don't belong conceptually to this library. Stream insertion is another problem domain: i. How do you serialize type `char`: as a numeric value, or as a graphical symbol ii. How do you serialize a pointer? As an address it represents? Do you make an exception for type `const char *`? Do you make an exception for type `char32_t const*`? iii. How do you separate the individual values? What character do you use for grouping them? iv. How do you allow users to control what happens for individual types? v. What if the user is nonetheless disappointed with your design choices? These issues go far beyond providing a tuple-like access to aggregates. They should be addressed by a separate library built on top of PFR. 5. Docs say, "provides other std::tuple like methods for user defined types without any macro or boilerplate code."This is not actually the case. In order to get the operators for aggregates -- at least in one mode -- one has to use a macro. 6. I would also say that this is inconvenient that the library, as documented, allows me to inject all the operators or none. I cannot opt into taking only relational operators. At least this is not documented. But I cannot honestly complain about it, because I do not agree with PFR synthesizing any of these operations at all. FInally, I wanted to thank Antony for writing and sharing this library here. I learned a great lot from it. I didn't realize that such reflection was possible in C++17. I hope that my review does not sound discouraging. Regards, &rzej;

4 15

[JSON][review] Result
by Pranam Lashkari 05 Oct '20

05 Oct '20

I would like to thank Vinnie Falco and Krystian Stasiowski for developing this library and bringing it to the boost. I will try to keep the mail short and point to point. ---- RESULT ---- Boost.JSON is ACCEPTED into the Boost. Now the process to transition repository to boost can start and get this library published in next release according to the guidelines. There was some heat around the discussion, I would like to clarify that this is not a completely democratic decision. Though there are more accept votes but I was a bit leaned toward the arguments made in the favour of reject as those arguments were analysed thoroughly and on point and I agreed with them. On the other hand, considering the targeted audience and the goal of the library those arguments are weighed less in my opinion. "Can't reject an Apple because it is not an Orange". In general, the library looks great to me and I am sure it will attract new users too because it has good documentation, friendly APIs and design and good performance too. ---- REVIEWS ---- There was a good amount of discussion and definitely more reviews than I expected including a few first-time reviewers. Summary: Accept: 14 Reject: 3 Conditional accept: 1 Some positive reviews: It is very good, and meets the highest Boost standards. I mean both the > tutorial and reference sections. While doing this review I had to look at > the documentation of the competing libraries, and they are really bad. This > is why I can appreciate the big effort you put in making these docs. There > is a section "Comparison" that compares Boost.JSON to other JSON > libraries. > I personally think it should also mention the documentation. The design takes some time to get used to, but it fits well to the > problem being tackled (a JSON-DOM library). > Switching my codebases using RapidJSON to this library made the code > more readable and it will also allow me to get rid of a significant > amount of boilerplate. The fact that this value type has been highly optimized is the great > strength of this library. Design is very good. The parser interfaces and object building interfaces > meet my needs. I especially want to call out the pmr support and it's > support for either sharing or transferring ownership of resources. Some critical reviews: Binary size matters a lot, since onboard Flash is very limited. I am > using a "big" MCU, and that means my whole binary must be under ~512 KB. > Right now Boost JSON is not great. In doing a simple serialization and > parse, the library itself adds ~58 KB to my .text section. This is OK for > now, but surprisingly big. I know the team is aware of this and has some > ideas to reduce the binary size. I will likely need those fixes to actually > port my app to Boost JSON. It would be better for the library to just template on allocator just like > the vector class in the C++ standard ...and many more positive and critical reviews... A Thing I was explicitly asked to note: > The memory management model is extremely simple. I wonder if storage_ptr > could be moved somewhere else long term so other libraries can use it. I think that's it. I would like to thank everyone who was involved in the review process every review was important and gives new insight and helps to make boost better. Best of luck to the authors and the maintainers of the library. -- Thank you, Pranam Lashkari, https://lpranam.github.io/

7 17

[PFR] Some questions
by Gavin Lambert 05 Oct '20

05 Oct '20

This is not (yet?) a review, although I guess this could be counted as a partial review towards the current state of the docs; but after reading them I have several questions. 1. Why is the term "reflection" used at all? As far as I am aware, this is primarily used to refer to accessing member names from the structure, which is not something that this library provides at all, so at best this seems highly misleading. The original "magic get" name seems more appropriate since it is primarily about extending tuple-get to basic structures without boilerplate macros. 2. An up-front clarification on the limitations of supported structures would be nice. "Aggregate initialisable" is not a concept that everyone is familiar with. 3. What is the motivation for "flat" reflection to exist, at all? I can't find any explanation of why one might want to do it; other than completely disregarding type safety, which seems like a bad thing. (I assume there is some reason that I'm not aware of, but that's why an explanation would be nice.) 4. Flat reflection is stated to be non-portable, raising further questions as to why it exists at all. 5. Many of the intro pages talk about "disabling loophole" with no explanation of what that is. The configuration macros page finally presents a link that doesn't really explain anything anyway, other than suggesting it is a Dark Magic that was intended to be banned but nobody had gotten around to it yet. 6. Speaking of the configuration macros page, it doesn't indicate what values are the defaults, other than it "auto-detects your compiler". I assume from the surrounding text that it would prefer to use C++17 and would use "loophole" (whatever that is) otherwise, but it would be good to make that (or whatever it actually does instead) explicit. Granted #3 can't get you into *too* much trouble with the limitation on only supporting aggregate-initialised types... but on the other hand, type hierarchies are still significant for aggregates (it can be important to distinguish a "handle" from a plain int, or a Boost.Units value from another with different unit). And it feels like you're doing C++ wrong if you're using aggregate types much; they're only a little better than PODs. (In all existing codebases I use, there are almost no aggregate types, although there are a few almost-aggregates that have simple initialising constructors, for example, or make member fields private and use a get-set method pattern "just in case". I imagine this is likely to be true of most real-world codebases.) Having said that, I can see some value in aggregate types as DTOs (for database/json/etc translation) and for reducing usage of std::pair and std::tuple, which is a good thing, though only if used in limited scope. But that usage doesn't explain "flat" either; the type hierarchy still should be important. Precise reflection, on the other hand, seems more potentially useful, save for the unfortunate -- though understandable -- limitation on only aggregates. Having said that, I've personally never found a use-case for a tuple-like get interface for anything, so perhaps I'm just not the target audience for this library. (I also have a strong dislike for aggregate initialisation being order-based in the first place; I would have preferred something like C99's named initialisation. C++20 is adding something that they're calling that, but is utterly useless and crippled instead of doing it properly.)

4 6

traits
by Gero Peterhoff 03 Oct '20

03 Oct '20

Hello Peter, I've designed a couple of traits here. Is that right so far so that they can be included in boost? But there are these problems: 1) char8_t is still missing in your is_unsigned 2) my implementations of - is_native; if the type exists natively on the platform - is_vectorisable; if the type can be vectorized on the platform (simd) - is_integer are still incomplete, as I cannot find out whether the corresponding types are available; e.g. on some platforms there is int56_t, but no int8_t (__CHAR_BIT__ > 8), etc. The specializations of is_logic and is_rational should better be done in the libs. If a concept is created, it is stored in boost::mata so that there are no naming conflicts. Similar to math::constants there is also a string::constants; maybe also makes sense. regards Gero

2 3

new type traits
by Gero Peterhoff 03 Oct '20

03 Oct '20

Hello Developers, I would like to retrofit some type-traits in boost, but I have read https://pdimov.github.io/articles/phasing_out_cxx03.html. Now I don't know how to do it best, as the boost-type-traits may be removed. Would the following procedure make sense? We get the std-traits and concepts in a namespace boost::meta, eg file boost/type_traits/meta.hpp: #ifndef BOOST_META_HPP #define BOOST_META_HPP #include <type_traits> #if defined(__cpp_concepts) #include <concepts> #endif namespace boost::meta { template <typename Type> using is_integral = std::is_integral<Type>; template <typename Type> inline constexpr bool is_integral_v = std::is_integral_v<Type>; template <typename Type> using is_pointer = std::is_pointer<Type>; template <typename Type> inline constexpr bool is_pointer_v = std::is_pointer_v<Type>; ... all other #if defined(__cpp_concepts) template <typename Type> concept integral = std::integral<Type>; template <typename Type> concept pointer = is_pointer_v<Type>; ... #endif } // boost::meta #endif // BOOST_META_HPP Then you could possibly map this in boost/type_traits.hpp to boost:: (if that makes sense): #ifndef BOOST_TYPE_TRAITS_HPP #define BOOST_TYPE_TRAITS_HPP #include <boost/type_traits/meta.hpp> remove boost implementations namespace boost { using namespace boost::meta; } // boost #endif // BOOST_TYPE_TRAITS_HPP In this way, new traits can be added in boost/type_traits/meta.hpp that are based on the std-traits, e.g. is_logic namespace boost::meta { template <typename Type> struct is_logic : std::false_type{}; template <typename Type> inline constexpr bool is_logic_v = is_logic<Type>::value; template <> struct is_logic<bool> : std::true_type{}; #if defined(__cpp_concepts) template <typename Type> concept logic = is_logic_v<Type>; #endif } // boost::meta and in this case add in boost/logic/tribool.hpp namespace boost::meta { template <> struct is_logic<boost::tribool> : std::true_type{}; } // boost::meta Or do you have a better idea? regards Gero

6 15

[FPR] Some feedback
by Andrzej Krzemienski 03 Oct '20

03 Oct '20

Hi Everyone, Not sure if I will be able to provide a decent review, so I wanted to at least share some thoughts. 1. Do not use "reflection" in the library name. "Reflection" means "any information I could ever need about any part of the program". In particular, people might expect that you will be able to give the class member names; you cannot, and they will call it a bug in the library, because it implied that it would be able to do this, as this is what you expect from reflection. What this library does is to give a tuple-like access to class members (plus a number of things atop of this). Maybe it should be called Tuple-like Element Access (TEA)? 2. The library can only provide tuple-like access to classes that meet certain criteria, but these criteria are not obvious. Calling it an aggregate-initializable struct is not good enough: ``` struct B {}; struct D : B { int i, j; }; ``` Struct D is an aggregate (in C++20) and can be aggregate-initialized with three elements, but will not work with the library. I suggest you list requirements and give them a name. Bjarne Stroustrup called something similar a "flat": https://www.youtube.com/watch?v=ERzENfQ51Ck&feature=youtu.be&t=376 but I am not sure if this is the right one. Maybe "simple aggregate". This would help users prepare for what to expect. I do not know if this can be statically tested (like if a class has any base) but this does not matter as long as the requirements are listed in the docs. This concept is core to the library. 3. Does this library bring any value for arrays? It works for arrays, but arrays already provide index-based element access. 4. Thank you for writing and sharing this library. I really like it. Regards, &rzej;

4 3

[review][pfr] PFR review
by Hadriel Kaplan 02 Oct '20

02 Oct '20

Howdy, I vote to ACCEPT PFR into boost. It provides a form of reflection in a simpler manner than other solutions thus far, and for the types it can handle it’s really slick. My only minor complaint is with streaming, as discussed below. I’d also like to thank the author for responding to issues quickly on GitHub, and for bringing it to boost! - What is your evaluation of the design? Good.(?) I'm not sure how to differentiate this question from the implementation question, for this type of library. - What is your evaluation of the implementation? I didn’t study the internals, but rather used it as a user of the library. It has some behaviors I don’t personally like, but fundamentally it does what it says as far as I can tell. My only complaint is that unsigned char and signed char (and thus uint8_t and int8_t) are streamed as their char values, and thus as their unadorned ASCII characters. Since they can be non-printable values, I consider this behavior undesirable. Even as printable characters it is confusing to see - especially if the value happens to be a numeric character or a space or linefeed or whatever. The author pointed out I can choose to _not_ use the provided streaming operator, but instead roll my own streaming operator - and I did so. But I still think it’s not what the implementation should do out-of-the-box as a Boost library. Lots of aggregate types use uint8_t/int8_t for fields, I think. For example network protocol headers, data-driven-design structures to minimize cache line usage, bit fields, etc. Many (most?) people would have to write their own streaming operator due to this issue. Also, I’m a bit concerned with forward-compatibility. The definition of what constitutes an aggregate type is changing slightly in C++20, and becoming stricter I believe; so I’m worried users might find they can’t upgrade to C++20 while still using PFR for some types. But I don’t have a C++20 compiler easily available to me, so I can’t prove this to be an issue or not. (perhaps it’s not an issue at all) - What is your evaluation of the documentation? Good. It explains what needs to be explained, in a brief but reasonable manner. I didn’t study it that closely, however. - What is your evaluation of the potential usefulness of the library? In some ways this is a tough question to answer - in others it’s easy. It’s easy because - for the aggregate types it can support - it is far simpler than any other solution I know of, and thus very useful. But it’s also difficult to answer because at least for the code base in my day job, and everywhere I have worked previously, very few class/struct types would be usable with it in practice. It is not the case that it supports every aggregate type - it cannot (currently) support ones with empty base classes, including CRTP-based empty bases. We happen to use CRTP frequently in my code base; for example boost::operators. And we have a lot of data structures that are _almost_ aggregates, except they end up having either one or more private members, or user-provided constructors, or unions, or whatever. Even types in our data-driven-design code areas, ended up not being true aggregates over time. But this is not something PFR can fix or address, as far as I’m aware, nor a reason to reject it - I’m merely pointing it out as something that reduces the applicability of such an approach. (Ironically PFR is making me consider changing some of them to be true aggregates, just so that we could use PFR - so I guess in that way it’s good? :) I presume, however, that there are plenty of code bases that have lots of true aggregates, and without empty bases - and for them it would be _extremely_ useful I would think. - Did you try to use the library? Yes. I did NOT try every possible operation that PFR makes available - I mostly only did streaming/printing, iteration, and member access by index. - With which compiler(s)? Gcc 7.3, C++17 mode. - Did you have any problems? My biggest problem was finding a C++ type in my code base that PFR could support. :) There was also the printing/streaming issue described earlier. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Just a few hours of using it. - Are you knowledgeable about the problem domain? No, not really. I have never tried implementing “reflection" without using macros that required the user to identify the type’s name and all of its members. (If one can call that “reflection”) As far as I’m concerned, PFR is black magic and if this were the 17th century I would report the author to church officials. -hadriel

5 7

[PFR] The user's perspective
by Andrzej Krzemienski 02 Oct '20

02 Oct '20

Hi Everyone, I am now trying to study the PFR library, and wanted to share some thoughts and see what others think. First, thanks Antony for writing and sharing this library. I have watched your video on it, read the docs, and I find it amazing that you were able to implement such reflection in C++. This is in the spirit of the good old Boost libraries that just implemented magic. Now, to the critique. From looking at the docs and the videos, I inferred (perhaps incorrectly) that the library was created in this order: "We can do type introspection for aggregates, so let's see to what extent we can provide an interface of a reflection library." The extent is quite amazing (e.g., I really appreciate having pfr::less<> out of the box), but to the end user, I think, the library will still appear as incomplete. That is, when my type is an aggregate it will work, but when I need to add a convenience constructor it will immediately break, and I will have to switch to another library, like Peter's Describe ( https://github.com/pdimov/describe/tree/master) With Describe, I will have to type more, but I have a guarantee of a uniform experience both for aggregates and for other types. And given that I have to use Describe at some point there may be no point in also keeping PFR and forcing on myself and my colleagues two different interfaces. Describe is not a perfect solution either, because for aggregates I have to declare the mapping, which is unnecessary as PFR has demonstrated. My ideal solution would be if these two libraries (PFR and Describe) would be merged into one, so that: 1. They provide the same interface 2. A user can easily instruct the library: "this is an aggregate: figure out the mapping yourself". I am sorry if it sounds arrogant: people are devoting their private time to write and share a cool library, and all they hear back is "do more." But I thought it would also be unfair not to give this feedback. I am also not sure if the goals of the two libraries are compatible (e.g., Describe is also interested in giving names of the members) . I would be curious to see what the authors think about it. Regards, &rzej;

5 6

Cache Size
by Matt Borland 01 Oct '20

01 Oct '20

A recurring discussion in Boost.Math has been needing a cross-platform way to query the L1D cache size of a machine. I have most of a solution in a [personal repo](https://github.com/mborland/cache). It did not make sense to us to have this in Boost.Math because it would be useful outside of that scope, but we did not know where it should go. Is there an existing library where this would fit? If necessary I can roll it into a library submission that exposes the functionality of CPUID. Matt

3 3

[review][json] My review
by Gavin Lambert 30 Sep '20

30 Sep '20

- Do you think the library should be accepted as a Boost library? Yes, my vote is to ACCEPT this library. - What is your evaluation of the design? Much has been debated recently on the merits of push parsers vs. pull parsers. Boost.JSON provides both a push parser (SAX-like interface) and a DOM parser (which is somewhat pull-like but I don't think is technically either kind). It does not provide a "real" pull parser, which are sometimes more efficient for deserialisation into custom types; the SAX parser can somewhat do that but is not composable, which makes it harder to use in practice, unless I'm missing something (this is usually why I end up never using SAX parsers). If so, I'd like to see a more complete example where the handler delegates part of the parsing to a class that in turn delegates part to another class (as with reading typed sub-values). I don't think this is currently possible. So I think I can understand some of the debate around this point; while I don't think it's strictly necessary that this particular library implement that, if it doesn't then another library will end up having potentially competing types and the natural Boost.Json name will already be taken. Personally, however, I don't think this is sufficient reason to block acceptance of this library. Direct pull parsing doesn't mesh well with JSON, due to the requirement to tolerate reordered keys, so any non-defective parser would have to have something DOM-like under the hood anyway. (Some kind of cache, if not necessarily a traditional DOM.) As such it should be sufficient to use json::value itself as part of a pull-like parsing interface. Regarding the SAX parser specifically, I dislike the *_part methods in the callback interface. I feel that these should be removed and only the final form retained, called only when the complete text of the value has been determined. I don't feel it is ever sensible to call back with a partially-parsed value (unless I am misunderstanding what these are for, but there is little explanation in the docs, and I wasn't able to get them called at all in my test). I also don't see the point of supplying a size argument to on_key* and on_string, as this can be read from the string_view argument instead. The various number methods don't pass this separately. Similarly, having a bool return as well as an error_code output argument seems peculiar; one or the other should be sufficient, as is it just invites inconsistency. parser.write() is incremental but basic_parser.write() is not, which seems odd. I assume this means that parser is storing an incrementally populated buffer of the full document rather than _really_ incrementally parsing. parse/parser do not appear to support consuming only part of the supplied input as a complete JSON value (returning how much was consumed), which is useful for streams where multiple objects are concatenated without explicit separation. Regarding other aspects of design, I haven't drilled down in great detail but the basic interface seems reasonably sound, other than the concerns raised above. I have mixed feelings on the initializer-list construction method -- I like that there is some method of doing this, and it seems like idiomatic C++ (particularly regarding how key-value pairs appear), but also very non-JSON -- an array of objects ends up having three nested braces. But I don't have any specific suggestion for improvement. - What is your evaluation of the implementation? It seems unfortunate (though understandable, due to heap allocation) that you cannot declare a json::value / json::object as constexpr, for cases where you do want some kind of constant reference object (e.g. a schema description). You can somewhat work around this by declaring the JSON as a constexpr string_view and later parsing it to a non-constexpr json::value, but that seems a bit awkward (and potentially bad-perf-prone if someone parses it multiple times). Otherwise I didn't really look into the implementation at all. - What is your evaluation of the documentation? Overall, good, if perhaps a bit sparse on some aspects. One pet peeve however is that most of the examples appear to be written as if "using namespace boost::json" is in effect, which I feel both encourages bad practice and makes it harder to distinguish which types are provided by the library vs. exist only for the example. This is especially confusing in the examples for tag_invoke, but not only there -- another example of confusion are the aliases for types present in both boost and std namespaces. I strongly recommend going through and changing these to explicitly use a json:: namespace prefix on all library types (including the boost/std aliases). Brevity is useful, but not at the expense of clarity. The "Using Numbers" section of the docs appears to be entirely blank. "serializer can be used to incrementally serialize a value incrementally" (redundant words are redundant) (On a related note, an example use case for serializer is listed as "ensure a fixed amount of work is performed in each cycle", but the only means of control is the length of the provided buffer. I guess this is equating work to number of characters output, which seems dubious. But I have no specific objections.) - What is your evaluation of the potential usefulness of the library? The library seems well suited for JSON as inter-process/network data interchange, other than perhaps the omission of partial input parsing. It seems less suited for JSON as configuration file -- while it can parse such files (via common extensions such as ignoring comments and trailing commas) it lacks means to pretty-print and to round-trip the comments, which would be essential if writing back a config file intended for human use. However while supporting this use case would be nice, I don't consider it mandatory. - Did you try to use the library? With what compiler? Did you have any problems? I tried it out with MSVC 2017 in standalone header-only mode, though only with a few small examples. The basic_parser examples do not compile out of the box -- with the suggested json.hpp and src.hpp includes there are link errors with basic_parser symbols. Additionally including basic_parser.hpp resolves these but starts complaining about missing max_{key,string,array,object}_size members of the handler type, which are not documented. After these are supplied then it works as expected. I don't see why these should be needed, however. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Roughly four hours over a few days reviewing docs and trying some small experiments. - Are you knowledgeable about the problem domain? I have some apps that use JSON as both interchange and configuration storage formats, although most of these do not use C++. So, "somewhat".

9 23

Review Manager needed for Boost.Lambda2
by Peter Dimov 30 Sep '20

30 Sep '20

Greetings, Some time ago I wrote a blog post, https://pdimov.github.io/blog/2020/07/22/a-c14-lambda-library/, which described how a simple lambda library can be implemented in ~50 lines using the facilities already available in C++14's <functional> standard header. I turned this into a mini-library, https://github.com/pdimov/lambda2, and I'd like to submit that to Boost. I'm looking for a review manager. The library is trivial, so managing the review should be as easy as theoretically possible for a Boost review. Thanks in advance.

7 20

new macros
by Gero Peterhoff 28 Sep '20

28 Sep '20

Hello Developer, can you please provide these 2 macros: - BOOST_HAS_LIB_INT128 - BOOST_NO_INT8_T and there is another bug in boost::is_unsigned with char8_t. See https://godbolt.org/z/o8z1aq thx Gero

1 0

[review][JSON] json::value as a vocabulary type
by Andrzej Krzemienski 26 Sep '20

26 Sep '20

Hi Everyone, I have heard this claim a number of times: json::value is suitable for a vocabulary type. I am not sure what that actually means: no templates? Guarantee that layout or mangled symbol will never change? Anything else? My understanding of a "vocabulary type" is that it should be usable (not necessarily with maximum efficiency) for *any* usage. In the case of JSON that would mean that I should be able to represent any value that corresponds to a valid JSON when converted to text. I do not think that json::value can claim that without the ability to serialize arbitrarily big numbers. I understand that the goal of the library is to address the most common cases, and big numbers do not fall into this category. I am just saying that the name "vocabulary type" may not be accurate here. Regards, &rzej;

11 25

Changing virtual memory amount in Appveyor and Travis CI tests
by Edward Diener 25 Sep '20

25 Sep '20

Is it possible through .yml file for Appveyor and Travis CI to change the amount of virtual memory when running a CI test. I am running CI tests for Boost PP which heavily use the preprocessor, and some of the extended tests I am running fail on both Appveyor and Travis CI with out of memory conditions while on my own local computer, with about 32 GB of ram, the tests succeed. I think in the real world most users now have at least 32 GB of ram or more, while these virtual environments in Appveyor and/or Travis CI probably run their tests with much less overall virtual memory than an average user would have.

4 12

Re: [boost] Endorsement, review manager sought for Boost.Describe
by Peter Dimov 24 Sep '20

24 Sep '20

> Vinícius dos Santos Oliveira wrore: > > Hi Peter, > > > > could you consider using "compile-time strings" such as Hana's? I don't > > have much use for a const char* in TMP algorithms. > > The descriptor strings are "compile-time". This, for instance, works. ... Here's how you can get a Hana string: #include <boost/describe.hpp> #include <boost/mp11.hpp> #include <boost/hana.hpp> #include <cstddef> using namespace boost::describe; using namespace boost::mp11; enum E { v1 }; BOOST_DESCRIBE_ENUM(E, v1) constexpr std::size_t strlen_( char const * s ) { std::size_t n = 0; while( *s++ ) ++n; return n; } template<class D, std::size_t... I> constexpr auto to_string_impl( index_sequence<I...> ) { return boost::hana::string_c<D::name[I]...>; } template<class D> constexpr auto to_string() { return to_string_impl<D>( make_index_sequence<strlen_(D::name)>() ); } using D = mp_first< describe_enumerators<E> >; constexpr auto st = to_string<D>(); #include <typeinfo> #include <cstdio> int main() { std::printf( "%s\n", typeid(st).name() ); }

1 0

Endorsement, review manager sought for Boost.Describe
by Peter Dimov 24 Sep '20

24 Sep '20

I would like to submit a C++14 reflection library, Describe, to Boost and I'm looking for endorsements and a review manager. The library is at https://github.com/pdimov/describe and the documentation is at https://pdimov.github.io/describe/doc/html/describe.html. Some examples of what the library enables are given at https://pdimov.github.io/describe/doc/html/describe.html#examples. The purpose of Describe is to establish a standard way of annotating (describing) user-defined types (enums, structs and classes), so that types can be described once, and then their descriptions can be used from other libraries. At the moment, the practice is for each library to invent its own ad-hoc annotation/description mechanism.

7 9

[nowide] cxx11_moveable_fstreams target
by Sean Farrow 24 Sep '20

24 Sep '20

Hi All, By way of context to the following query, I am trying to update the VCPKG boost port to v1.74. I noticed that the nowide library now has a jam file that has the following import statement: import ../../config/checks/config : requires ; Due to the way VCPKG works, I'm copying the config directory to where it is expected and then changing the import statement. But I then get a message that it can't find the cxx11_moveable_fstreams target. Does the nowide build process rely on any other parts of boost config? If not, where is the cxx11_moveable_fstreams defined? I should say that I'm new to the boost build system, so any help is apreciated. Thanks, Sean.

5 9

[review][JSON] The library name...
by Andrzej Krzemienski 24 Sep '20

24 Sep '20

Hi Everyone, Looking at the reviews of Boost.JSON, a number of them fall into a distinctive pattern: reviewers are saying "you did not implement important parts of JSON parsing/serializing", and the authors' reply is "this was not the design goal". My hypothesis is that this is caused by the library name. Simple "Boost.JSON" makes a promise (at least I read it this way) "this is Boost's response to JSON-related problems". And the library does not fulfil that promise. In a sense, the name misguides the potential users who need an answer, sometimes in less than 10 seconds, to the question, "is this library going to address my need?". Maybe the library would encounter a wider consensus if it was called Boost.JSON_Value, or Boost.JSON_DOM. And if the first introductory sentence in the documentation read, "this library provides a type with Regular interface that can represent JSON contents, and provides a convenient way to serialize and then deserialize it fast and possibly in chunks." Alternatively, maybe we can consider the reviewed library as a candidate for a sub-library in a more general module of JSON. Much like Boost.Math aggregates a number of math-related components, we could treat this library as one of a number of components in a more general Boost.JSON_Toolkit library. Regards, &rzej;

1 0

Proposal for adding C++ level to the meta/libraries.json
by Edward Diener 24 Sep '20

24 Sep '20

Since we are reviewing Vinnie Falco's JSON library I thought that this would be a good time to present a proposal to add information to each Boost library's meta/libraries.json file regarding the level of C++ standard compliance for that library. This could then be added to each library's visual documentation so that end-users would instantly know the C++ standard level they would need to use in order to use a Boost library. My proposal is to add 3 fields whose data would be the same as the cxxstd allowed values from Boost Build, using the first value of each choice ( currently 03, 11, 14, 17, 20 ). standard = minimum C++ level for the library extended = same functionality in the library as the minimum C++ level but with extended use given higher C++ levels required = new functionality in the library above the minimum C++ level which requires given higher C++ levels The 'standard' field would be a single value, while the 'extended' or 'required' fields could be more than one comma separated value. If you don't like the names for 'standard', 'extended', or 'required' you can bikeshed the name, although I think the 'standard' name is pretty well apparent. The idea is to provide this information in the meta/libraries.json field for each library, so that the end-user of the library can immediately know the usability of the library with appropriate C++ standard levels of compilation. I realize that the line between the 'extended' and 'required' entries, as I have described them, could be blurred. The 'standard' field remains the most important. I have long felt that the end-user should not have to do any investigation, in code or in documentation, just to determine if a library is usable for his C++ standard level of compilation.

12 27

[review][JSON] Ruthgers' review
by Ruthger Dijt 23 Sep '20

23 Sep '20

> Do you think the library should be accepted as a Boost library? It will be a good addition to Boost if this library gets ACCEPTed > What is your evaluation of the design? It works, is straightforward and the interface feels good to use, the only pitfall is getting the right type you want; number_cast took me a second to realize it existed and the custom string class is something the will most likely be converted alot to std::string in an average users' code. > What is your evaluation of the implementation? As a casual user I cannot comment on this, but as I used it in stand alone / header only mode without problem I feel that i should be alright under the hood > What is your evaluation of the documentation? Could be better, especially in the examples department; it could use how-to basics > What is your evaluation of the potential usefulness of the library? Very useful > Did you try to use the library? With what compiler? Did you have any > problems? I have implemented it in a real project where RapidJSON was used before. No real problems found aside from getting exceptions because .as_double() is not able to get a technically integer from the json (which happens in user configs, example: { "test": 20 }) but that quickly resolved itself with number_cast, Ideally any number should be able to become a double in my opinion. Clang 10.0.1 was used. > How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? As stated above implemented in one project which took about an hour. > Are you knowledgeable about the problem domain? No, this review is coming from a pure casual user kindly, Ruthger Dijt

2 1

[json][review] JSON review
by Harshada Wighe 23 Sep '20

23 Sep '20

We vote to reject the JSON library from Boost and our review of the library and reason for rejection are below: DOCUMENTATION The documentation is very good. The usage and examples and reference are easy to understand and contain all the information we are looking for. IMPLEMENTATION The organization of source code is very messy: 1. Some files do not include all headers at the very start of the file but have some include statements at the end. For example the json/object.hpp file has 10 include statements at the start of the file before the opening namespace and then 1 include statement at the end of the file after the closing namespace. This is very confusing and not a good practice. 2. Splitting the files into HPP and IPP is also not good because it spreads the class into more files than necessary and causes compilation to be slower. Using the library in a project has a complication: 3. The library is complicated to use in a project because you cannot simply include headers in any file you want. You have to include a src.hpp file but this file must be included only once. Normal header libraries in Boost just let you include the headers without this strange requirement. The library adds a lot of size to your executable: 4. Unlike other JSON libraries which are smaller, this adds several KB to the exe size. This is possibly because of use of templates or because it contains very big lookup tables. The performance is not as fast for all use cases: 5. Compared to our in house JSON library, this library was slightly slower. We have very simple but very large JSON data. We use objects and arrays, but only integer numbers with no fractional part and very large ASCII strings, and no booleans and no nulls. In one of our standalone conversion tools we tried using this library and found it had a 4% longer runtime on a small 170 MB file. The parser allocates too much memory: 6. I think this is because the design is not optimized for the case when all the JSON content is already stored in memory. In our parser we point to the strings in the original buffer. The library duplicate code that is in the C++ compiler libraries: 7. In json/config.hpp there are implementations of move and remove_cv from the C++ standard. This introduces more duplicate of this functionality into programs. Besides these points the implementation is well written. DESIGN The allocator design is not standard: 1. The library has a different allocation system that is not the C++ standard system for allocators. We did not understand why storage_ptr was needed at first. It would be better for the library to just template on allocator just like the vector class in the C++ standard. The allocator system also uses virtual calls. The C++ standard vector class also does not have this problem when it uses the standard allocator system. Other than these points the design is ok. OVERALL We would not use this library because it does not offer anything special for JSON that we need. It also uses some designs that are not standard practice. We use JSON heavily in our historical market quote service and most of our tools deal with JSON files and we use many Boost libraries so we are hoping for a JSON library in Boost that we could use instead of having our own.

3 2

[json][review] Scott Determan review
by Scott Determan 23 Sep '20

23 Sep '20

I recommend ACCEPTING the proposed json library. - What is your evaluation of the design? Design is very good. The parser interfaces and object building interfaces meet my needs. I especially want to call out the pmr support and it's support for either sharing or transferring ownership of resources. It's unfortunate that this required a non-standard string class, but I think supporting shared ownership is worth it. I also like the use of tag_invoke for customization points. Apart from libunifex, this is the first library I've seen that uses this mechanism. I think this is the right way to do customization points. - What is your evaluation of the implementation? I looked at the value, storage_ptr, and object classes. It appears to be a very high quality implementation. However, I did this only as a sanity check, I did not spend much time looking at the implementation. The benchmarking numbers also point to a high quality implementation. - What is your evaluation of the documentation? Documentation is very good. Message for Vinnie: One minor nit caught my eye: My understanding is when implementing a tag_invoke customization point it should be a hidden friend because it improves compile times by keeping overload sets smaller. If that is best practice (and it may not be; I'm not a tag_invoke expert), then the examples in the documentation should follow this. - What is your evaluation of the potential usefulness of the library? It covers a widely useful range of json functionality and I expect this library to be widely used. If accepted I intend on using it immediately. - Did you try to use the library? With which compiler(s)? Did you have any problems? Yes: gcc 10.2 and clang 10.0.1; Linux; No problems. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Read the documentation, browsed the code, wrote some toy programs. Spent about half a day on it. - Are you knowledgeable about the problem domain? As a library consumer, I am familiar with nlohmann_json as well as the custom json library used in my current work project. I am not familiar with the problem domain from a library writer point of view.

2 1

[review][json] Boost.JSON review
by Ruben Perez 23 Sep '20

23 Sep '20

Hi all, My recommendation is to ACCEPT Boost.JSON into Boost. Parsing and serializing JSON using a DOM representation is a common enough task to have a specialized library for it in Boost. Most other languages provide built-in support for this task. I see Boost as the repository where I look at when the standard doesn't provide me something it should, so having a DOM JSON library in Boost is a must for me. - What is your evaluation of the design? Generally sound. I especially value its simplicity. Concretely: 1. The memory management model is extremely simple. I wonder if storage_ptr could be moved somewhere else long term so other libraries can use it. 2. Using concrete types for numbers (uint64_t/int64_t/double) may not fit everyone's needs but will definitely fit most and makes things easy. I miss some way of accessing json::value from generic code, but I understand visitation is currently in progress. As a user I would also be satisfied with generic versions of get_xxx, is_xxx and so on: ```cpp json::value val = /* ... */ val.get<json::object>() // or json::get<json::object>(val) ``` I also miss some way of determining the location (line and column) of parse errors. I don't know how this feature would interact with performance though. Nice to have but not required for me. I would have also liked `json::kind` be streamable, as it makes logging/debugging easier in some contexts. Nothing I can't live without, though. Finally, I would also appreciate `json::string` have a straightforward way to be converted to `std::string` (e.g. by having a `to_std_string()` member function). - What is your evaluation of the implementation? I have just looked at the interface. - What is your evaluation of the documentation? The documentation is very good and detailed, nice work. I would say the main point of improvement would be `basic_parser`, as I had a hard time understanding when some of the callbacks get called, especially the `on_xxx_part` ones. It would be also good to know if accessing the `basic_parser` state (e.g. `depth()`) is allowed from within the handler. And if it is, maybe passing the parser instance at the beginning of the parse could be useful (e.g. in the `on_document_begin`, or in a separate hook). Ideally I would like to see an example of `basic_parser` used to parse a custom struct, if it's not excessively complex. Also note that `basic_parser` docs say that it's defined in `<boost/json/detail/basic_parser.hpp>` and that the convenience header is `<boost/json.hpp>`. Instead, it would be good to note that the user should include `<boost/json/basic_parser.hpp>` and that `<boost/json.hpp>` is not enough (I understand for build speed reasons). I've noted that streaming a `json::string` outputs the string within double quotes. It surprised me at first, as I was working with the 'json::string equals std::string' mentality. I guess this behavior makes sense, but I would make a note in the 'Using strings' section. 'See also' section for https://master.json.cpp.al/json/ref/boost__json__value_from_tag.html renders functions without separation, looks strange. I would make a note in the Value conversion mechanism referencing P1895 on `tag_invoke` so users who don't know this paper don't stare at the name wondering 'why?' As a final note, googling 'Boost json' renders this link to an old version of the docs: http://vinniefalco.github.io/doc/json/index.html Consider removing it so users don't get confused (I did at the very beginning). - What is your evaluation of the potential usefulness of the library? I think it will be incredibly useful. Parsing to DOM and serializing from DOM are very widespread tasks, and having a simple, well designed `json::value` container makes things much better. I would have used it for my use cases if it had been available. - Did you try to use the library? With which compiler(s)? Did you have any problems? I used the library in the Boost version and separate compilation model. I built and installed the library using CMake 3.16.3 and g++ 9.3.0 on Ubuntu 20.04, with no problems. I then built several toy examples with the library's CMake `find_package` interface. No problems. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent around 10h reading the documentation and building examples. - Are you knowledgeable about the problem domain? I have used JSON as a data exchange format in the embedded, financial and web worlds, in C++ and other languages (JavaScript, Python and PHP). In C++ I have mainly used rapidJSON, and I would replace it with Boost.JSON for future developments. I have no experience writing JSON libraries myself. Thanks, Ruben.

3 3

Re: [boost] [review][json] My review
by Gavin Lambert 23 Sep '20

23 Sep '20

At 00:22 24/09/2020, Vinnie Falco wrote: >On Wed, Sep 23, 2020 at 1:40 AM Gavin Lambert wrote: >> I've walked back on that one a little bit; I now think that it's >ok for >> basic_parser to do that (to retain a zero-allocation guarantee) >but in >> that case it should treat numbers the same way (which it >currently >> doesn't), and ideally there should be a standard >slightly-higher-level >> parser that has a similar interface but does preassemble the >values, >> eliminating the _part callbacks (for people who prefer ease of >use over >> raw performance). > >I had that originally, it was called number_parser, it was a >public >interface, and it was one of the first things to go during our >3-month >journey of optimization. You can fish it out of the commit log if >you >care to see it. I didn't fish out the code, but given the class name, that sounds like the complete opposite of what I was suggesting. To restate again, my suggestion is: 1. Remove on_int64/uint64/double from basic_parser's handler type. 2. Add on_number(string_view, size_t) to basic_parser's handler type -- having exactly the same semantics as on_key/string and their _part companions. 3. Add custom_parser, which wraps a basic_parser but has internal (dynamically allocated if needed) storage for partial keys/strings/numbers so it never calls _part methods on its own handler type. It still uses on_number(string_view) but note that this (and on_key/string) have no reason to pass a size_t any more, because it can never be any different from the size() of the string_view. 4. The int64/uint64/double parsing code that used to be in basic_parser should be moved to a dedicated helper class, in turn used by parser and *optionally* used by the user's handler implementation for basic_parser/custom_parser. This design has the proper separation of concerns between the parser layers (not dictating a numeric storage format, and keeping number parsing separate from JSON structural parsing). It should not negatively impact performance of parser, and should positively affect performance of basic/custom_parser consumers who didn't want the default conversion anyway.

2 1

[review][JSON] RJanson's review
by Janson R. 22 Sep '20

22 Sep '20

This is a review from a library user standpoint. Thanks to Vinnie, Krystian, and the other contributors for their work. > Do you think the library should be accepted as a Boost library? I recommend ACCEPTING this library into Boost. > - What is your evaluation of the design? The design takes some time to get used to, but it fits well to the problem being tackled (a JSON-DOM library). Switching my codebases using RapidJSON to this library made the code more readable and it will also allow me to get rid of a significant amount of boilerplate. > - What is your evaluation of the implementation? Looks solid. Boost-quality I find. > - What is your evaluation of the documentation? Solid. A month ago I still had to read the source code to find some details, but now all I need for my use-cases is in the docs, well explained. > - What is your evaluation of the potential usefulness of the library? Very useful; to me it takes the same place as Nlohmann.JSON and RapidJSON, both very popular and widely used libraries, but brings better performance and a better API. Regardless of the outcome of this review, I will use this library for my future JSON-DOM needs in C++. > - Did you try to use the library? With which compiler(s)? All in standalone mode on Debian: GCC 9, 10 Clang 9, 10, 11 [trunk of 03 Jul 2020] > - How much effort did you put into your evaluation? Converted two of my codebases (which have different use-cases for a JSON-DOM), read through the implementation, read the docs at multiple stages of its maturation over the last couple months. Amounts to about 40h. > - Are you knowledgeable about the problem domain? I do not have much experience designing nor writing libraries, however I do use a significant number of them, both Boost and non-Boost. JSON is my primary format for configuration files and web communication; In the past I have used Nlohmann.JSON and then primarily RapidJSON for its speed, despite its (in my eyes) terribly user-unfriendly interface. I have also used JSON a lot in other languages (TypeScript, PureScript, Java). -- RJanson

2 1

[JSON[review] Andrzej's review
by Andrzej Krzemienski 22 Sep '20

22 Sep '20

Hi Everyone, I recommend to *ACCEPT* the library into Boost. It meets the standard for BI am definitely going to use it. I tried to use the library in two configurations in header-only mode: g++ 9.2.0 with -std=c++2a on MinGW on Windows, g++ 10.2.1 on Fedora with -DBOOST_JSON_STANDALONE and -std=c++20 All worked fine. I studied library docs and played with examples for about 30 hours. I am not particularly knowledgeable about the problem domain. But my programs have to consume and produce JSON files. DOCUMENTATION It is very good, and meets the highest Boost standards. I mean both the tutorial and reference sections. While doing this review I had to look at the documentation of the competing libraries, and they are really bad. This is why I can appreciate the big effort you put in making these docs. There is a section "Comparison" that compares Boost.JSON to other JSON libraries. I personally think it should also mention the documentation. Some observations: 1. Add reference to RFC 7159 (https://www.rfc-editor.org/info/rfc7159) It allows implementations to set limits on the range and precision of numbers accepted. 2. The documentation for array object and index mention "Satisfies the requirements of ContiguousContainer, ReversibleContainer, and SequenceContainer" These requirements are never defined or referenced. The user will not even know if you defined them or if they are "commonly known". Maybe add link to cppreference.com: https://en.cppreference.com/w/cpp/named_req/ReversibleContainer https://en.cppreference.com/w/cpp/named_req/ContiguousContainer https://en.cppreference.com/w/cpp/named_req/SequenceContainer 3. String has two sections "Member Functions": https://master.json.cpp.al/json/ref/boost__json__string.html 4. Documentation for value::operator= seems corrupt: https://master.json.cpp.al/json/ref/boost__json__value/operator_eq_/overloa… * it has sections with no content * It is an unconstrained template, it look like it can accept any type 5. Examples of input JSON-s contain a lot of escape characters in string literals, like in https://master.json.cpp.al/json/usage/conversion.html This makes it difficult to read. Consider using raw string literals. Instead of assert( serialize( jv ) == "{\"x\":4,\"y\":1,\"z\":4}" ); We would have assert( serialize( jv ) == R"({"x":4,"y":1,"z":4})" ); 6. Some functions (like operator== or swap(x, y)) are naturally part of class interface, even though they are not member functions. It is annoying and confusing that rather than being listed along with the class they belong to they are instead listed separately as "free functions" The docs are not uniform about this issue. For `json::value` operator== is listed as friends along with other member functions, but not 2-argument swap(). 7. In https://master.json.cpp.al/json/usage/conversion.html we read: " Given the following definition of customer::customer( const value& ) [...] Objects of type customer can be converted *to* and from value". This "to" is surprising here. How can a constructor converting from `value` to `customer` could be used to convert `customer` to `value`? 8. As discussed in another thread, documentation would benefit from the info on implementation-limits-related design choices. a. Any json::value that you can build can be serialized and then deserialized, and you are guaranteed that the resulting json::value will be equal to the original. b. JSON inputs where number values cannot be represented losslessly in uint64_t, int64_t and double, may render different values when parsed and then serialized back, and for extremely big number values can even fail to parse. c. Whatever JSON output you can produce with this library, we guarantee it can be passed by any common JSON implementation (probably also based on uint64_t+int64_t+double implementation. DESIGN Clear, sound and practical. The design decisions correspond with my expectations of a library: fast, easy to use and learn, with value semantics. The interface is very intuitive, I practically do not have to consult the documentation: every functionality (serialization, value alteration) has the interface that I would expect. I appreciate that it targets embedded environments. Some observations: 1. The handling of infinities and NaN's needs to be addressed. Currently, I can do: `json::serialize(std::numeric_limits<double>::infinity())` and t produces an invalid JSON. You cannot easily make a precondition on json::value assignment/construction because you expose the double as a mutable member: void fun(double x) // precondition x is not infinity or nan { json::value v = x; // ok v.as_double() *= 2.0; // this may produce infinity } So maybe you need a precondition in the serializer. 2. Boost.JSON provides its own string type. This begs a lot of design questions for `json::string`. Is it a better replacement for std::string? std::string provides the following capability: ``` void set(std::string& s, char v, char x, char z, char k) { if (cond) s = {v, k}; else s = {v, x, z, k}; } ``` json::string does not. How do I do a similar thing with json::string? 3. string::swap() has a strange precondition: you cannot swap an object with itself https://master.json.cpp.al/json/ref/boost__json__string/swap.html This is a really unexpected and potentially dangerous, and at minimum requires a very strong rationale. This would be the first swap function in std or Boost that has a precondition. While discussing a somewhat related issue (on the guarantees of the moved-from state) in the LEWG, someone remarked that there was at least one STL implementation that did a self-swap for convenience of implementation. Is it really necessary? IMPLEMENTATION I didn't look at it much. Just some quick points I observed. 1. Values of type `double` representing Infinity and NaN can be stored in json::value and when later serialized, they render a malformed JSON output. json::value should either validate special values of `double` or indicate as precondition that they should not be assigned. Alternatively, the serializer should either validate this or indicate as precondition. 2. tag_invoke() takes tag arguments by reference, does it have to? Passing by reference requires the constexpr variables to be instantiated and their address assigned. 3. Customization through ADL-discovered overloads can cause ODR violations. There is no superior alternative though. But maybe put a warning in the docs that the user must make sure that all translation units must see the same set of overloads. 4. I do not like the 2-state-switch mechanics of BOOST_JSON_STANDALONE. It assumes that a user either wants a no-Boost version or that she wants a package: all Boost components. But what if I am using C++14 and I want to use std::error_code and Boost-emulated memoty_resource and string_view? What If I use Boost version and C++17 and want to use std::string_view? Maybe you can additionally provide macros for turning Boost-emulation libraries one-by-one? I mean, one for string_view, one for error_code, and one for memory_resource. 5. The header only mode -- I really appreciate it. It is good for initial experiments. Finally, I would like to thank Vinnie and Krystian for writing and sharing this library. Regards, &rzej;

3 4

[FPR] FPR review starts Sept 28
by Benedek Thaler 22 Sep '20

22 Sep '20

The Boost formal review of the FPR (Flat Precise Reflection, ex Magic Get, ex PODs Flat Reflection) will take place from September 28, 2020 to October 7, 2020. The library is meant for accessing structure elements by index and providing other std::tuple like methods for user defined types without any macro or boilerplate code. The library is authored by Antony Polukhin, author of Boost.DLL, Stacktrace, Type Index libraries. Documentation: http://apolukhin.github.io/magic_get/ Source: https://github.com/apolukhin/magic_get If the description isn't immediately obvious for you, here's a motivating example: // requires: C++14 #include <iostream> #include <string> #include "boost/pfr/precise.hpp" struct some_person { std::string name; unsigned birth_year; }; int main() { some_person val{"Edgar Allan Poe", 1809}; std::cout << boost::pfr::get<0>(val) // No macro! << " was born in " << boost::pfr::get<1>(val); // Works with any aggregate initializables! } See more at: https://github.com/apolukhin/magic_get/blob/develop/README.md Benedek

1 0

[JSON][Review] Another Boost.JSON review
by Hadriel Kaplan 22 Sep '20

22 Sep '20

Howdy, I vote to ACCEPT Boost.JSON into boost. I think it’s a fine implementation for what it’s intended for. I don’t understand some of the other reviews that reject it for not being something else - they got an apple and are complaining it’s the wrong color for an orange. It’s fine to prefer oranges over apples, but it’s also ok to offer apples for sale in your store even if you wouldn’t buy it yourself. A lot of people like apples - they’re simple and convenient, without having to peel away the layers of complexity involved in something more pulpy. (Ok, I’ve squeezed as much juice out of that metaphor as possible...) - What is your evaluation of the design? Good. It took me a bit to get used to it, because I was used to something else (Facebook’s folly::dynamic mostly); but that would be true of any new library. - What is your evaluation of the implementation? I didn’t study the internal details. I used it as a consumer of the library. I thought the user-facing API was reasonable. The one change I made to the code was to force it to use std::string_view instead of boost::string_view, even though I used it in non-standalone mode. It would be nice if there were a separate compile flag for that, but it’s not a big deal. Having yet another custom/purpose-built string implementation was surprising. It’s not an issue, but just surprising that yet another string type is being created. It was also a bit surprising there wasn’t a function to pretty-print the serialized output (e..g, via an option arg for `serialize()`). It’s fairly common to need such a thing, for example to write to user-viewable files (e.g., configuration or property files), and potentially to debug logs, etc. Obviously the user can write a pretty-printer of their own, but this is one of those things that I think should come out-of-the-box eventually. - What is your evaluation of the documentation? Very good. As a consumer, it had most everything I needed. - What is your evaluation of the potential usefulness of the library? I think it’s very useful. Whether it will become _popular_ I don’t know. There’s no debate there is high demand for a JSON-based variant-structure library similar to Boost.JSON, but there are several popular choices already. Boost.JSON has better performance and memory usage than some of the ones I know of (nlohman and folly::dynamic), so that should give it a leg up. But those libraries also have a lot of bells and whistles, and it’s not clear how much that will matter to people. While my company also has a custom implementation for some specific uses, we do still use folly::dynamic fairly heavily, and I would seriously consider migrating to Boost.JSON in our code-base instead. - Did you try to use the library? Yes, I used it in non-standalone mode, and ran it through some tests we have in my employer’s code base. - With which compiler(s)? Gcc 7.3, C++17 mode. - Did you have any problems? Just a couple bugs that were quickly fixed by the authors. One test failure I got was with the usage of scientific notation in serialized output, as has been noted by other reviewers. It’s not _wrong_, of course, but it’s unusual - and unusual is frequently bad for interoperability. Also, I first tried it in standalone and was surprised it didn’t work even though we use C++17 - sadly, gcc 7.3 doesn’t have the pmr::memory_resource implementation. Gcc doesn’t have pmr until version 9+, which is a shame because incorporating it as standalone would be ideal; we do use boost heavily, but we almost always have issues when upgrading boost versions, so we don’t upgrade often. I think being usable as standalone would increase the uptake for Boost.JSON… but requiring gcc 9+ negates that somewhat, perhaps. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent about a day testing it. I’m sorry I didn’t have more time this past week. Life happens. :( - Are you knowledgeable about the problem domain? I’ve been using `folly::dynamic` from Facebook’s folly library since 2014, and have made changes to it for my company’s code base. It provides a similar variant-style structure based on JSON-ish types, with a parser and serializer for JSON encoding. I’ve also written a custom JSON-based variant-structure for some of my company’s particular needs, with built-in schema support, JsonPointer and XPath-style query support, etc. -hadriel

2 1

Re: [boost] [review] [json] My JSON review
by Vinnie Falco 21 Sep '20

21 Sep '20

On Mon, Sep 21, 2020 at 10:29 AM Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> wrote: > > > In both cases, I'd like to read/write my data from/to JSON with the > > > same framework. > > > > Why? What specifically, is the requirement here? > > What I'd like is a way to describe how my C++ types map to a key-value > structure with normalized types so that I can easily convert my > objects back and forth through a structured self-describing and > human-readable interchange format. Right, but what I'm asking you is: *specifically* in what way would a framework that offers both JSON DOM and JSON Serialization be "consistent?" Can you show in terms of declarations, what that would look like? In other words I'm asking you to show using example code how putting these two separate concerns in a single library would offer benefits over having them in separate libraries. Thanks

3 3

[review] [json] My JSON review
by Mathias Gaunard 21 Sep '20

21 Sep '20

Hi, This is my review of Boost.JSON by Vinnie Falco and Krystian Stasiowski. I believe that the library should be REJECTED, though it would me a much better candidate with just a few minor tweaks here and there. The library provides the following components: - a parser framework - a DOM to represent/construct/edit trees of JSON-like values (json::value) - a serializer for that type Unfortunately, all three of these components are not quite satisfactory when it comes to addressing the problem domain of JSON as an interchange format. JSON is ubiquitous technology, and I feel like this library is not deserving of a name such as Boost.JSON, which would suggest "the right way to do JSON as seen by the C++ community". Parser: -------- Parsing is arguably the most important feature of any such library. However with Boost.JSON it really feels like it is an afterthought, and only its coupling with json::value was considered. These are the main issues: - The lack of proper number support from the DOM apparently propagates to the parser as well, even though there is no cost for the parser to properly support them. - The interface is closely tied to a text format and doesn't support JSON-inspired binary formats. This kind of forward thinking is what would really elevate those parsers. - The fact that only a push parser is provided. Parsing into own types usually requires a pull parser in order for nested member's parsers to combine into the outer parser. The way the parser interfaces handles numbers is not only inconsistent with the rest of its interface but also limiting. bool on_number_part( string_view, error_code& ) { return true; } bool on_int64( std::int64_t, string_view, error_code& ) { return true; } bool on_uint64( std::uint64_t, string_view, error_code& ) { return true; } bool on_double( double, string_view, error_code& ) { return true; } I would expect an interface that looks like bool on_number_part( string_view, std::size_t n, error_code& ) { return true; } bool on_number( string_view, std::size_t n, error_code& ) { return true; } bool on_int64( std::int64_t, error_code& ) { return true; } bool on_uint64( std::uint64_t, error_code& ) { return true; } bool on_double( double, error_code& ) { return true; } I see the push parser nicely integrates with beast/asio segmented buffering and incremental parsing, which is nice. DOM: ------ The DOM provides a canonical or vocabulary type to represent any JSON document, which is useful in itself. The DOM does not support numbers that are neither 64-bit integral numbers nor double-precision floating-point. This is a common limitation, but still quite disappointing, since the proposal of it being a canonical type is quite tainted by the fact it can't represent JSON data losslessly. I think it would be better if another type was provided for numbers that don't fit in the previous two categories. It uses a region allocator model based on polymorphic value, which is what the new polymorphic allocator model from Lakos et al. was specifically intended for. It puts some kind of reference-counting for life-extension semantics on top, which I'm not sure I'm a big fan of, but that seems optional. Querying capabilities for that type are pretty limited and quite un-C++ like. Examples use a C-style switch/extractor paradigm instead of a much safer variant-like visitor approach. There is no direct nested xpath-style querying like with boost property tree or other similar libraries. It feels like the interface is only a marginal improvement on that of rapidjson. Serializer: ----------- There is no serializer framework to speak of: just a serializer for the DOM type json::value, i.e. the only way to generate a JSON document is to generate a json::value and have it be serialized. A serializer interface symmetric to that of the parser could be provided instead, allowing arbitrary types to be serialized to JSON (or any other similar format) without conversion to json::value. When it comes to serializing floating-point numbers, it seems it always uses scientific notation. Most libraries have an option so that you get to choose a digit threshold at which to switch. Integers always use a fixed representation, which makes this all quite inconsistent. Review questions: ---------------------- > - What is your evaluation of the design? I can see the design is mostly concerned with receiving arbitrary JSON documents over the network, incrementally building a DOM as the data is received, and then doing the opposite on the sending path. It is good at doing that I suppose, but however is otherwise quite limited as it is unsuitable for any use of JSON as a serialization format for otherwise known messages. > - What is your evaluation of the implementation? I only took a quick glance, but it seemed ok. Can't say I'm a fan of this header-only idea, but some people like it. > - What is your evaluation of the documentation? It is quite lacking when it comes to usage of the parser beyond the DOM. It also doesn't really say how numbers are formatted in the serializer. > - What is your evaluation of the potential usefulness of the library? Limited, given the scope of the library and the quality of its interface, I don't see any reason to use it instead of rapidjson, which is an established library for which I already have converters and Asio stream adapters. > - Did you try to use the library? With which compiler(s)? Did you have any problems? I didn't. > - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Maybe half a day reading through the documentation and the mailing list. > - Are you knowledgeable about the problem domain? I have used a lot of different JSON libraries and I have written several serialization/deserialization frameworks using JSON, some of which are deeply tied into everything I do everyday.

5 14

[JSON][Review] Boost Json Review
by Maximilian Riemensberger 21 Sep '20

21 Sep '20

My review is primarily from the perspective of a library consumer. I use boost libraries and JSON on a daily basis. But neither did I ever write a boost library nor a JSON library. # Boost JSON Review > Please provide in your review information you think is valuable to > understand your choice to ACCEPT or REJECT including JSON as a > Boost library. Please be explicit about your decision (ACCEPT or REJECT). I recommend ACCEPTing the library into boost. It's well designed, professionally implemented and fills an important use case. The library is well maintained and I trust the authors to keep doing so. The documentation is good, but I the reference documentation could use some improvements in a few spots. Individual reference sections appear copy-pasted a bit too aggressively, which is clearly good for the doc writer but not so much for the doc reader. I consider none of the issues below show-stoppers that would block acceptance into boost. This is also based in the experience that the authors are responsive in maintaining the library (and other libraries) and I trust them that they will use their best judgement and whether and how to address any issues. Brief side note: I'm a user of boost libraries and I consider boost a very important part of the C++ library ecosystem, in particular, for building reliable and long lasting software components and systems. It sets a high bar for acceptance. When using individual boost libraries, an important consideration is whether the library has aged well with the evolution of the C++ standard, whether it is currently well maintained and whether it will remain well maintained in the future. Here boost sometimes appears to be a bit of a mixed bag. So I consider the maintenance promise to be quite important and in particular more important than any of the issues raise below. I want to thank all the people involved in boost for keeping it alive, useful and high quality. > Some other questions you might want to consider answering: > > - What is your evaluation of the design? I evaluated primarily the DOM interface, that is the value container, but didn't look into the parser and serializer in detail. The design is solid and clear. Smaller issues raised on slack during the review have been addressed. I particularly like that it provides an easy to use, automatic ownership allocator interface. It relieves me from the pain of manually maintaining the life-time of non-global memory pools etc. Minor comments: - The `value::is_xxx` functions inconsistently return bools or pointers. This can have unexpected consequences if they are use from a context that does not implicitly convert to bool. Also I really can't remember which one returns what. For example, `is_null`, `is_bool`, `is_number`, `is_string`, `is_structured` returns a really nice mix. (Fixed on develop) - The library provides `initializer_list` construction for `value`. I personally would prefer it wouldn't do that. Too many pitfalls with a missing pair of braces causing the meaning to change quite dramatically. Still I think many expect them in modern JSON libs. So it's up to the authors. - The library is inconsistent about `shrink_to_fit`. `object does not have it, `array` has it. Also the documentation does not state what `shrink_to_fit` does, basically repeating the errors of `std::vector`. I firmly believe that the function should either be removed or clear and precise semantics should be documented. In it's current state the following question comes to mind: Why would I ever want to call it? > - What is your evaluation of the implementation? I looked at the implementation of the `value` container. I did not look into the parser and serializer. The implementation appears clean and professional. The authors responded quickly to issues raised while studying the source code. > - What is your evaluation of the documentation? The documentation is generally good and well structured. However, the reference is occasionally pretty terse. Some parts of it are written with the assumption that any user going to the reference section has recently read the entire documentation including examples upfront. Some comments (mostly against master and develop from early Sep 20): * `value::storage()` should say: Return a reference to the `storage_ptr` to the `memory_resource` associated with the value. The same thing applies to a few other classes. * The reference for the `initializer_list` constructor could use some improvements: e.g. "Construct an object or array from an `initializer_list`". I find this hugely important since just the mere presence of an `initializer_list` constructor changes the meaning of brace initialization. * Additionally, I doesn't mention how nested `initializer_list` how are treated. Most importantly it should show or link to some examples on how the `initializer_list` are converted to objects, arrays, and non structured values because some developers (if not most) might not immediately realize from just looking at the reference documentation how nested `initializer_list` are parsed. Maybe also reference to the `initializer_list` constructors of `array` and `object`. * `object::insert` is not well-documented. I did not understand what it does when I insert an already existing key, in particular, whether assignment takes place or not. The same is true for `object::emplace`. * The `object` initializer constructor is listed under "Copy constructor". * The `object::erase` return value documentation is wrong. * `object::reserve` says "This inserts an element into the container." * `object::swap(object)` and the friend version `swap(object,object)` have rather inconsistent briefs. * The initializer_list constructor for array is listed under move constructors. * The pilfer constructors are not quite explained. There's a reference to the paper, but I think the library should have a page that concisely explains what it does and what a user of the library can expect from pilfered objects. In particular, how the thing differs from move and why a user would ever want to use it instead of move. Also the reference pages for pilfer and so on don't explain what it does. * `array::reserve` shows `BOOST_FORCEINLINE` in the docs. * `value_to` is unclear about the precedence of the three listed options (constructor, library provided conversion or `tag_invoke`) if multiple are present provided this is actually possible. The same is true for `value_from`. * `storage_ptr` thread safety is not documented. That's a real bummer for a `shared_ptr`-like construct. * I found it rather difficult to figure out the difference in the behavior of `parser::write` and `parser::write_some` just from reading the documentation. Either reference documentation should clearly state what the difference is. I had to open both pages side by side to actually spot the wording difference. For example, I think that the documentation of `write_some` should clearly state that it's intended use case is for parsing multiple JSON values from a byte stream presented through one or more buffers whereas `write` is intended for parsing one JSON value from one or more buffers. At least that's what I concluded from the documentation after some time. * The `parser` documentation should either link to or inline provide one or more examples how the parser is supposed to be used. In particular `write_some` would benefit hugely from an example that shows how to properly extract a stream of JSON values from a sequence of buffers. * If I read the documentation correctly, `basic_parser::write` behave more like `parser::write_some` than `parser::write`. I would prefer the call it `basic_parser::write_some`. * The `basic_parser` reference documentation would benefit from either a link to an example or an inline example. > - What is your evaluation of the potential usefulness of the library? I think the library supports a very narrow yet widespread use-case. It offers a modern interface and high performance. So I will definitely use and I believe it will also be useful to a wide audience. > - Did you try to use the library? With which compiler(s)? Did you have > any problems? I played with it in its STANDALONE mode with gcc 9.3. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? Roughly 5 hours playing with small examples, but mostly looking into the documentation and into the code of `json::value` and related parts of the DOM implementation. > - Are you knowledgeable about the problem domain? I use JSON on a regular basis across different languages including c++ (mostly nlohmann's up to date). I've not implemented a JSON library myself. Kind regards, Max

3 4

[review][JSON] Boost.JSON Review starts Sept 14
by Pranam Lashkari 20 Sep '20

20 Sep '20

The boost formal review for JSON will take place from Sept 14, 2020 to Sept 23, 2020. JSON is authored by Vinnie Falco (author: boost beast and Static String), Krystian Stasiowski(author: Static String) and submitted with of Peter Dimov(author: Too many libraries to mention 😛) The use of JSON format to share the data is getting bigger and wider because it is lightweight and it's supported cross-platform and many more. JSON has numbers of uses and to make our life easy to deal with it in C++ this library is introduced. Documentation can be found here: <http://vinniefalco.github.io/doc/json/> It includes examples, usage and comparison. Documentation is still under progress but still provides enough information. Official repository: <https://github.com/CPPAlliance/json> Glad to address any questions or issues, here or in the repo: <https://github.com/CPPAlliance/json/issues/> The purpose of this announcement is to give people some time to start looking at the documentation and source code for the library. Feel free to begin asking questions. Most of all, get involved! Nowadays most of us(assuming) would have dealt with the JSON in one way or another. Tell the Boost community what you think of JSON. -- Thank you, Pranam Lashkari, https://lpranam.github.io/

5 8

Reviewing Boost.JSON
by Vinícius dos Santos Oliveira 19 Sep '20

19 Sep '20

I'm gonna use a perhaps unusual text structure for this review. Consuming text is a tiring activity that demands energy. Having that in mind, I ignored the order in which the library is presented through the docs and moved all trivial concepts discussion to the end. That's my attempt to make sure the message gets through while the reader still has it -- the energy. ## A short introduction to pull parsers vs push parsers The act of parsing an incoming stream will generate events from a predefined set. Users match the generated events against rules to trigger actions. For the following JSON sample: ```json { "foo" : 42 , "bar" : 33 } ``` One of such event streams could be: ``` begin_object -> string_key -> number -> string_key -> number -> end_object ``` The essential difference between pull parsers and push parsers is how this event stream is delivered. A push parser (a.k.a. SAX parsers) uses the callback handler model. A pull parser (a.k.a. StAX parsers) stores the current parsing state and allows the user to query this state. Essentially every push parser has an implicit pull parser that doesn't get exposed to the user. This is to say that a push parser would be implemented in the lines of: ```cpp // parsing loop while (it != end) { match_token(); dispatch_token(user_handlers); } ``` Whereas a pull parser doesn't have the loop construct above, just its body. The loop construct would be under user-control. That's why pull parsers are the more fundamental model. A push parser can be built on top of a pull parser, but not the inverse. Concrete examples will be shown later in this text. ## Performance: a common misconception Some push parsing proponents believe pull parsers are slower. This belief is unsubstantiated. As we have seen in the previous section, a push parser is always built on top of an implicit pull parser. The only thing that differs them both is that a small part of the parser logic under the pulling model moves out of the interface to become user code. That's the only difference. One of the arguments brought by push parser proponents is the ability to merge matching and decoding steps to perform less work. We can use the previous sample to illustrate this idea: ``` { "foo" : 42 , "bar" : 33 } ^^^^^ ``` If we are to decode the `"foo"` token above, the parser first needs to discover where the token begins and where the token ends. This is the required matching step that every parser needs to perform. JSON strings can be escaped and one such example would be: ```json "na\u00EFve" ``` The decoding steps take care of converting escaped string slices to unescaped ones. So user code would receive 3 string runs while this token is being decoded: - "na" - "ï" - "ve" The parser does not allocate any memory to decode any string. The slices are feeded to the user who in turns is responsible to put them together (possibly allocating heap memory). The idea here is... having separate match and decode steps forces the parser to walk over the tokens twice. For Boost.JSON, the merged match and decode steps materialize in the `on_string_part()` (and `on_string()`) callback: ```cpp bool on_string_part(string_view v, std::size_t, error_code& ec) { current_str.append(v.data(), v.size()); return true; } ``` For a pull parser with _separate_ match and decode steps the interface would be in the lines of: ```cpp reader.next(); if (reader.kind() == token::string) reader.string(current_str); ``` But as we've seen before, the only difference between pull and push parsers is something else. Any features lateral to this classification originate from different taxonomies. Just as a push parser can merge the matching and decoding steps so can a pull parser: ```cpp // A new overload. // // `my_match_options` here would provide // the string collector upfront. reader.next(my_match_options); ``` Another small note here is that just as merging matching and decoding steps can be beneficial performance-wise so can skipping the whole decoding step. I'll be touching on this very idea again in the section below. Appendix A will present how another feature from Boost.JSON can be implemented in pull parsers: strings split among different buffers. ## The case for pull parsers So far we've only been exposed to the difference between push parsers and pull parsers, but there wasn't a case for which choice is ideal (aside from the naturally understood concept that pull parsers are more fundamental and push parsers can be built on top when desired). The defining trait present in pull parsers that is impossible to replicate in push parsers is their ability to compose algorithms. Composition is enabled by temporarily handing over the token stream to a different consumer. Not every consumer needs to know how to process every part of the stream. That's a trait impossible to find in push parsers. I have created a [gawk](https://www.gnu.org/software/gawk/) plug-in to illustrate this property. The same plug-in was implemented several times using different libraries/approaches. I incrementally added more features under different branches (there are 8 branches in total). You can find a rationale for the AWK choice in Appendix B by the end of this review. The plugin's code can be found at <https://gitlab.com/vinipsmaker/gawk-jsonstream-archive>. And you may forgive my beginner code, but I had no experience to write gawk plug-ins beforehand. That's my first. AWK is a C-like language (in syntax) where you define pattern-action pairs. You can find a quick'n'dirty introduction to the language from Wikipedia. This plug-in adds JSON capabilities to the tool. Given the following data-set: ``` {"name": "Beth", "pay_rate": 4.00, "hours_worked": 0} {"name": "Dan", "pay_rate": 3.75, "hours_worked": 0} {"name": "Kathy", "pay_rate": 4.00, "hours_worked": 10} {"name": "Mark", "pay_rate": 5.00, "hours_worked": 20} {"name": "Mary", "pay_rate": 5.50, "hours_worked": 22} {"name": "Susie", "pay_rate": 4.25, "hours_worked": 18} ``` And the following AWK program (with this plug-in loaded): ```awk BEGIN { JPAT[1] = "/name" JPAT[2] = "/pay_rate" JPAT[3] = "/hours_worked" } J[3] > 0 { print J[1], J[2] * J[3] } ``` The output will be: ``` Kathy 40 Mark 100 Mary 121 Susie 76.5 ``` The paths for the JSON tree are given in [standard JSON Pointer](https://tools.ietf.org/html/rfc6901) syntax. That's the plugin's core and it's the code that doesn't change among branches, so it's the appropriate place to begin the explanation. In the file `jpat.ypp` you'll find a `read_jpat()` function that gets called for each record. There's some boilerplate in the beginning to bail out earlier if there were no changes to `JPAT`. Then there is this snippet that gets processed by [re2c](https://re2c.org/) to generate valid C++ code: ```cpp * { if (*begin != '\0') return bad_path(); jpat[i].components.emplace_back(std::move(current_component)); goto end; } {prefix} { jpat[i].components.emplace_back(std::move(current_component)); current_component = std::string{}; goto loop; } {unescaped} { current_component.append(begin, YYCURSOR - begin); goto loop; } {escaped_tilde} { current_component.push_back('~'); goto loop; } {escaped_slash} { current_component.push_back('/'); goto loop; } ``` The definitions for the data structures follow: ```cpp struct Path { std::vector<std::string> components; awk_value_cookie_t cookie = nullptr; awk_string_t orig; }; struct Tree: std::map<std::string, std::variant<Tree, size_t>> {}; static std::vector<Path> jpat; Tree tree; ``` By the end of the re2c-generated loop, the variable `jpat` will be filled. Then there is some validation/sanitization steps and we start to fill the `tree` variable out of the extracted paths. `tree` is a decision tree auxiliary to the process of parsing the JSON documents. Leaf nodes represent which index in the `J` AWK variable will receive that value. Given the following `JPAT`: ```awk JPAT[1] = "/foo/bar" JPAT[2] = "/foobar" ``` `tree` will have the following properties (pseudocode): ```cpp // AWK arrays are 1-indexed, so the code // translation has a 1-element offset assert(tree["foo"]["bar"] == 0); assert(tree["foobar"] == 1); ``` The user may find other uses for a JSON decision tree in Appendix C. And here is where the code branches diverge. So let's present an overview and then walk them one-by-one (or two-by-two): ``` +------------+---------------+--------------+ | | Boost.JSON | pull parser | +------------+---------------+--------------+ | basic | boostjson | master | | dom | boostjson-dom | | | transform | boostjson2-b | master2 | | transform2 | boostjson3 | master3 | +------------+---------------+--------------+ ``` The `master` branch is just 506 lines of C++ code total and `boostjson` is 613 lines. The description for the other branches follow: - `dom`: built after `basic`. This branch is useful to highlight performance differences between the DOM parser and the rest. - `transform`: `boostjson2-b` is built on top of `boostjson-dom` branch. `master2` is built on top of `master` branch. It adds the power to update the JSON document. Here we start to notice how the ability to mark certain points in the token stream are important for a JSON library. - `transform2`: built on top of the previous branch, it adds the `JUNWIND` operation in the likes of MongoDB's `$unwind` operator. The first thing I'll do is to compare the DOM parsing layer cost. [There's this 161MiB JSON file that'll be used](https://drive.google.com/file/d/1-lVxGYWvvmBsjrDVgju_lOTBaK03MdQc/vie…. Just as `jq` can be used to extract a field from this file: ```bash jq -cM '.features[10000].properties.LOT_NUM' citylots2.json ``` So can AWK: ```bash gawk -l jsonstream -e ' BEGIN { JPAT[1] = "/features/10000/properties/LOT_NUM" } { print J[1] }' citylots2.json ``` The execution time for the boostjson branch will be: ``` real 0m2,112s user 0m1,476s sys 0m0,618s ``` And the execution time for the boostjson-dom branch will be: ``` real 0m5,639s user 0m4,170s sys 0m1,418s ``` We should always strive to do more than just throwing random numbers. Anyone can do that. The timings show that the DOM layer is obviously much slower, but there is no surprise here. It's kind of ridiculous trying to compare both branches. They do different things (although the plug-in feature-set is the same). The DOM approach will always decode and save every matched token. And that's one of the principles to deliver faster code: do less. The reason why I've chosen a 161MiB JSON file was to make sure most of the program's time would be spent not in the gawk VM but in the parsing plug-in. If we wanted to expose every value from the DOM tree, `json::value` would also be useless because the consumer here expects `awk_value_t` objects (and the DOM interface would guarantee the costs for unnecessarily saving decoded results twice would be paid). We don't always control the interface/protocol -- that's part of the C++ programmer's job. Would it be reasonable to deliver code twice as slow to my client because "hey I have a nice DOM container... gotta use it"? As Marcel Weiher has noted in [his call for "less lethargic JSON support"](https://blog.metaobject.com/2020/04/somewhat-less-lethargic-json-support.html) [sic]: > Wait a second! 312MB/s is almost 10x slower than Daniel Lemire's parser, > the one that actually parses JSON, and we are only creating the objects > that would result if we were parsing, without doing any actual parsing. > > This is one of the many unintuitive aspects of parsing performance: the > actual low-level, character-level parsing is generally the least > important part for overall performance. Unless you do something crazy > like use `NSScanner`. Don't use `NSScanner`. Please. Let's dive in the code to see how they differ. ### `basic` Every branch reads a record one document at a line. That's the `get_record()` function. For the `boostjson-dom` branch, the code goes in the lines of: ```cpp try { parsed_value.emplace_null(); json_parser.reset(parsed_value.storage()); std::error_code ec; json_parser.write(line.data(), line.size(), ec); if (ec) throw std::system_error{ec}; json_parser.finish(ec); if (ec) throw std::system_error{ec}; parsed_value = json_parser.release(ec); assert(!ec); switch (parsed_value.kind()) { case json::kind::array: fill_j(parsed_value.get_array(), tree); break; case json::kind::object: fill_j(parsed_value.get_object(), tree); break; // ... } } catch (const std::exception& e) { warning(ext_id, "Error while processing record: %s", e.what()); } ``` The code parses the whole JSON at once and then follows to consume the document by calling the `fill_j()` function: ```cpp // Several overloads: static void fill_j(const json::array& arr, Tree& node); static void fill_j(const json::object& obj, Tree& node); static void fill_j(const json::value& v, Tree& node); // Here is the object overload. You can find the rest in the repository. static void fill_j(const json::object& obj, Tree& node) { for (auto& [key, value]: node) { auto it = obj.find(key); if (it == obj.end()) continue; std::visit( hana::overload( [&](Tree& tree) { fill_j(it->value(), tree); }, [&](size_t idx) { consume_value(it->value(), idx); }), value); } } ``` The code is pretty straight-forward. We check if the fields the user asked for are present in the document and recurse on them. When we reach a leaf node, the `J` AWK variable is set (that'd be the `consume_value()` function). Do notice that there is no uncontrolled recursion here. Recursion is always JPAT-delimited. And JPAT is part of the source code, not user-input. There is no risk of stack overflow here. The pull parser approach (branch master) somewhat follows the same trend, but the code is bigger. Here's a selected highlight: ```cpp void fill_j(json::reader& reader, Tree& node) { // ... switch (reader.symbol()) { case json::token::symbol::error: throw json::error{reader.error()}; case json::token::symbol::begin_object: { if (!reader.next()) throw json::error{reader.error()}; std::string current_key; for (;;) { if (reader.symbol() == json::token::symbol::end_object) { reader.next(); break; } // Key assert(reader.symbol() == json::token::symbol::string); current_key.clear(); auto ec = reader.string(current_key); assert(!ec); (void)ec; if (!reader.next()) throw json::error{reader.error()}; // Value auto it = node.find(current_key); if (it == node.end()) { json::partial::skip(reader); continue; } std::visit( hana::overload( [&](Tree& tree) { switch (reader.symbol()) { case json::token::symbol::begin_array: case json::token::symbol::begin_object: fill_j(reader, tree); break; default: json::partial::skip(reader); } }, consume_value), it->second); } if (reader.symbol() == json::token::symbol::error) throw json::error{reader.error()}; } // ... } } ``` And here is the first sample on what I meant by composability. Our "callback" only gets called to handle trees that are part of the decision tree one way or another (and the root node always belongs here). When it reaches a subtree that doesn't belong to the JPAT-defined decision tree, `json::partial::skip()` is called. `json::partial::skip()` is defined elsewhere and has no knowledge on the internals of our algorithm. This is a different "callback" being called to handle a different part of the tree. The two of them know how to handle different groups of tokens. A nice side effect is that these "phantom" trees will be fully skipped over. We don't allocate strings to collect values over them. This is an optimization we get for free. [Designing JSON parsers to exploit this idea is not unknown](https://github.com/zserge/jsmn). The last one will be the code for the `boostjson` branch, but I feel like it'll be easier to understand if I first introduce the tasks it has to perform in the token stream. ``` { "foo" : 42 , "bar" : { "foo" : 33 } } ^^ ``` When the field's value is parsed, we must match the key against our rule-set to possibly trigger an action. But it is not enough to store the current key. The whole path must be stored to support the JSON nest-able structure. We start with the structure to save current context information: ```cpp struct State { bool is_object; //< false = ARRAY std::string current_key; size_t current_idx; Tree* node; }; std::vector<State> state; ``` So the beginning of the code for `on_object_begin()` must be: ```cpp Tree* node = nullptr; if (state.size() == 0) { node = &tree; } else if (state.back().node) { auto it = state.back().node->find(current_key()); if (it != state.back().node->end()) node = std::get_if<Tree>(&it->second); } state.emplace_back(); state.back().is_object = true; state.back().node = node; ``` And a matching action in the code for `on_object_end()`: ```cpp state.pop_back(); ``` But it's not really that simple. Paths such as `/features/10000/properties/LOT_NUM` won't work because `current_key` won't be provided by any `on_key()`-like callback when current node is `10000`. `current_key` must be computed for arrays in the value handler itself. That's why the following snippet must be present in the beginning of every value-callback (and `on_{object,array}_begin()` too): ```cpp if (state.size() > 0 && /*is_array=*/!state.back().is_object) update_current_array_key(); ``` And the matching helper functions: ```cpp std::string_view current_key() { assert(state.size() > 0); return state.back().current_key; } void update_current_array_key() { assert(state.size() > 0); assert(!state.back().is_object); state.back().current_key.resize(max_digits); auto s_size = std::to_chars( state.back().current_key.data(), state.back().current_key.data() + state.back().current_key.size(), state.back().current_idx++ ).ptr - state.back().current_key.data(); state.back().current_key.resize(s_size); } ``` The final touch is to realize that the event stream will be something like: ``` string_key -> value -> string_key -> value -> string_key -> value -> ... ``` And we need to clear the `string_key` by the end of every value consumed: ```cpp if (state.size() > 0) state.back().current_key.clear(); ``` So the callback implementation for a simple atom value such as a string is: ```cpp bool on_string_part(std::string_view v, std::error_code&) { if (state.size() > 0) { if (state.back().node == nullptr) return true; auto it = state.back().node->find(current_key()); if (it == state.back().node->end()) return true; if (!std::holds_alternative<size_t>(it->second)) return true; } current_str.append(v.data(), v.size()); return true; } bool on_string(std::string_view v, std::error_code&) { awk_value_t idx_as_val; if (state.size() == 0) { current_str.append(v.data(), v.size()); make_number(0, &idx_as_val); } else { if (/*is_array=*/!state.back().is_object) update_current_array_key(); if (state.back().node == nullptr) goto end; auto it = state.back().node->find(current_key()); if (it == state.back().node->end()) goto end; auto idx = std::get_if<size_t>(&it->second); if (!idx) goto end; current_str.append(v.data(), v.size()); make_number(*idx + 1, &idx_as_val); } { awk_value_t value_as_val; char* mem = (char*)gawk_malloc(current_str.size() + 1); memcpy(mem, current_str.c_str(), current_str.size() + 1); set_array_element( var_j, &idx_as_val, make_malloced_string(mem, current_str.size(), &value_as_val)); } end: if (state.size() > 0) state.back().current_key.clear(); current_str.clear(); return true; } ``` But the code still performs differently. There's that optimization we got for free in the pull parser choice. We must implement a mechanism to skip over unwanted trees to make the comparison fair. And here's where a `skipped_levels` variable is introduced. It'll change every callback again but will finally let us have the following code for the `string_key` callback: ```cpp bool on_key_part(std::string_view v, std::error_code&) { if (skipped_levels) return true; // not called on phantom trees state.back().current_key.append(v.data(), v.size()); return true; } bool on_key(std::string_view v, std::error_code&) { if (skipped_levels) return true; // not called on phantom trees state.back().current_key.append(v.data(), v.size()); return true; } ``` The full code can be found on the `include/jsonstream/parser.hpp` file. This explanation should suffice to understand (to quote myself): > The defining trait present in pull parsers that is impossible to > replicate in push parsers is their ability to compose > algorithms. Composition is enabled by temporarily handing over the token > stream to a different consumer. Not every consumer needs to know how to > process every part of the stream. That's a trait impossible to find in > push parsers. Every callback depends on implementation knowledge from every other callback. Spaghetti code as they say. I also implemented another change to both branches -- `master` and `boostjson` -- to further demonstrate this property. What if we want to store string representation for array indexes in static arrays instead `std::string` objects? There's this changeset for `master` branch: ``` --- a/src/main.cpp +++ b/src/main.cpp @@ -184,20 +184,19 @@ void fill_j(json::reader& reader, Tree& node) case json::token::symbol::begin_array: { if (!reader.next()) throw json::error{reader.error()}; - std::string current_key; + std::array<char, max_digits> current_key; for (size_t i = 0 ;; ++i) { if (reader.symbol() == json::token::symbol::end_array) { reader.next(); break; } - current_key.resize(max_digits); auto s_size = std::to_chars(current_key.data(), current_key.data() + current_key.size(), i).ptr - current_key.data(); - current_key.resize(s_size); - if (node.count(current_key) == 0) { + auto it = node.find(std::string_view(current_key.data(), s_size)); + if (it == node.end()) { json::partial::skip(reader); continue; } @@ -214,7 +213,7 @@ void fill_j(json::reader& reader, Tree& node) } }, consume_value), - node[current_key]); + it->second); } if (reader.symbol() == json::token::symbol::error) ``` The changes are local to the code that parses this structure (only the `case json::token::symbol::begin_array` "callback" changed). It doesn't affect the rest. As for the `boostjson` branch, the code for every callback must now execute new code (if you're curious why we'd need a `current_key()` helper function): <https://gitlab.com/vinipsmaker/gawk-jsonstream-archive/-/commit/f4c81abf7e7…>. As an exercise for the reader, try to imagine what changes would be required in the push parser approach if we wanted to expose a DOM handle in the `J` AWK variable. As for the pull parser approach we have a call to `partial::skip()` within the `consume_value()` function. This call would be replaced with `partial::parse()` and that's the change. ### `transform` By now I already made my main point. Push parsers don't compose. I'll keep the explanation for remaining branches brief and only give an outline over them. We've made a plug-in to read JSON values. Naturally the next step is to have the ability to update/write them. It's not possible to do this with Boost.JSON parser, so I had to give up on branch boostjson2 and start a new one -- boostjson2-b. `boostjson2-b` is based on `boostjson-dom` so you can expect similar prohibitive costs from the DOM layer. The strategy here is the same as before. We recursively traverse the stored DOM using the decision tree to guide the whole process. The previous step had a `consume_value()` function and the new step will have a `produce_value()` one: ```cpp static void produce_value(json::value& dom, size_t idx) { awk_value_t idx_as_val; make_number(idx + 1, &idx_as_val); awk_value_t value; if (!get_array_element(var_j, &idx_as_val, AWK_UNDEFINED, &value)) { dom.emplace_null(); return; } switch (value.val_type) { case AWK_UNDEFINED: case AWK_ARRAY: dom.emplace_null(); break; case AWK_NUMBER: if (value.num_value == 1.0 && dom.is_bool()) { dom.emplace_bool() = true; } else if (value.num_value == 0.0 && dom.is_bool()) { dom.emplace_bool() = false; } else { // TODO: respect AWK's OFMT dom.emplace_double() = value.num_value; } break; case AWK_STRING: case AWK_REGEX: case AWK_STRNUM: { dom.emplace_string() = std::string_view{ value.str_value.str, value.str_value.len}; break; } case AWK_SCALAR: case AWK_VALUE_COOKIE: assert(false); } } ``` Then we just serialize the whole DOM tree when the AWK function `json::output()` is called: ```cpp static awk_value_t* do_output(int /*num_actual_args*/, awk_value_t* result, awk_ext_func_t* /*finfo*/) { query_j(parsed_value, tree); auto serialized = json::to_string(parsed_value); char* mem = (char*)gawk_malloc(serialized.size() + 1); memcpy(mem, serialized.c_str(), serialized.size() + 1); return make_malloced_string(mem, serialized.size(), result); } ``` For the pull parser we modify the read loop to store the document offsets (this small diff is the part impossible to achieve with Boost.JSON parser): ``` --- a/src/main.cpp +++ b/src/main.cpp @@ -96,6 +96,11 @@ void fill_j(json::reader& reader, Tree& node) // atom values at root level were moved out of this recursive function. auto consume_value = [&](size_t idx) { + Slice slice; + slice.rel_off = reader.literal().data() - cursor; + slice.jidx = idx; + slice.bool_src = false; + switch (reader.symbol()) { case json::token::symbol::end: case json::token::symbol::error: @@ -109,6 +114,8 @@ void fill_j(json::reader& reader, Tree& node) var_j, make_number(idx + 1, &idx_as_val), make_number(reader.value<bool>() ? 1 : 0, &value)); + + slice.bool_src = true; } if (false) case json::token::symbol::integer: @@ -133,12 +140,15 @@ void fill_j(json::reader& reader, Tree& node) make_malloced_string(mem, value.size(), &value_as_val)); } case json::token::symbol::null: + slice.size = reader.literal().size(); if (!reader.next()) throw json::error{reader.error()}; break; case json::token::symbol::begin_array: case json::token::symbol::begin_object: - json::partial::skip(reader); + slice.size = json::partial::skip(reader).size(); } + cursor += slice.rel_off + slice.size; + slices.push_back(slice); }; switch (reader.symbol()) { ``` And implement AWK `json::output()` to perform simple string concatenation: ```cpp static awk_value_t* do_output(int /*num_actual_args*/, awk_value_t* result, awk_ext_func_t* /*finfo*/) { size_t output_size = 0; for (auto& slice: slices) { output_size += slice.rel_off; slice.buffer.clear(); awk_value_t idx_as_val; make_number(slice.jidx + 1, &idx_as_val); awk_value_t value; if (!get_array_element(var_j, &idx_as_val, AWK_UNDEFINED, &value)) { slice.buffer = "null"; output_size += slice.buffer.size(); continue; } switch (value.val_type) { case AWK_UNDEFINED: case AWK_ARRAY: slice.buffer = "null"; break; case AWK_NUMBER: if (value.num_value == 1.0 && slice.bool_src) { slice.buffer = "true"; } else if (value.num_value == 0.0 && slice.bool_src) { slice.buffer = "false"; } else { // TODO: respect AWK's OFMT json::writer writer{slice.buffer}; writer.value(value.num_value); } break; case AWK_STRING: case AWK_REGEX: case AWK_STRNUM: { json::writer writer{slice.buffer}; writer.value(json::writer::view_type{ value.str_value.str, value.str_value.len}); break; } case AWK_SCALAR: case AWK_VALUE_COOKIE: assert(false); } output_size += slice.buffer.size(); } auto buffer_end = buffer.data() + record_size - record_rt_size; output_size += buffer_end - cursor; char*const mem = (char*)gawk_malloc(output_size + 1); auto out_it = mem; auto in_it = buffer.data(); for (auto& slice: slices) { memcpy(out_it, in_it, slice.rel_off); out_it += slice.rel_off; in_it += slice.rel_off + slice.size; memcpy(out_it, slice.buffer.data(), slice.buffer.size()); out_it += slice.buffer.size(); } memcpy(out_it, cursor, buffer_end - cursor); out_it += buffer_end - cursor; *out_it = '\0'; return make_malloced_string(mem, output_size, result); } ``` It's clear which solution will perform better here (string concatenation of a few string slices vs serializing the whole DOM tree again), but there is another interesting difference to highlight. The difference having nothing to do with pull parsers vs push parsers and everything to do with the serialization framework. As we can see from the alternative library here, we're able to serialize the document piece by piece. Boost.JSON has one serialization facility -- `json::serializer` and its by-products such as `json::to_string()` -- and that's it. If you have a domain object in the likes of: ``` struct Reply { int req_id; std::vector<std::string> result; }; ``` The only answer for Boost.JSON would be to first convert the whole object into `json::value` and serialize the resulting DOM tree. That's an unacceptable answer. ### transform2 For the last developed branches, I demonstrate how partial DOM trees fit in the design of pull parsers. MongoDB has this `$unwind` operator that will output a new document for each element in a certain array element of the input document. So, for the following document: ``` { "foo" 33 , "bar" : [ 3, 4, "abc" ] } ``` MongoDB's `$unwind` operator can be used to output: ``` { "foo" 33 , "bar" : 3 } { "foo" 33 , "bar" : 4 } { "foo" 33 , "bar" : "abc" } ``` For our plug-in, you just fill the index you'd like unwind: ```awk BEGIN { JPAT[1] = "/bar" JUNWIND = 1 #< index in JPAT array } ``` For `boostjson3` branch, the idea is to swap the desired array to a different place so we can later call `json::output()` cleanly: ``` --- a/src/main.cpp +++ b/src/main.cpp @@ -74,13 +74,32 @@ static const awk_fieldwidth_info_t zero_fields = { static json::parser json_parser; static json::value parsed_value; -static void consume_value(const json::value& v, size_t idx) +int unwind_idx; //< 1-indexed ; 0 is root ; -1 is unwind unset +json::array unwinded_values; +static bool unwind_in_progress; +static size_t nunwinded; + +static void consume_value(json::value& v, size_t idx) { switch (v.kind()) { case json::kind::array: + if ((int)idx + 1 == unwind_idx) { + v.get_array().swap(unwinded_values); + { + awk_value_t val; + auto ok = sym_update_scalar( + var_julength, + make_number(unwinded_values.size(), &val)); + assert(ok); (void)ok; + } + unwind_in_progress = true; + nunwinded = 0; + break; + } case json::kind::object: break; case json::kind::string: { ``` For `master3` branch, only one change happened to the read loop (again proving the composability of pull parsers). The idea is to store the unwind target directly into a domain object (so almost a partial DOM, but even cheaper). Do notice that only `json::token::symbol::begin_array` "callback" changed. Every other "callback" stays the same: ``` --- a/src/main.cpp +++ b/src/main.cpp @@ -146,6 +151,63 @@ void fill_j(json::reader& reader, Tree& node) if (!reader.next()) throw json::error{reader.error()}; break; case json::token::symbol::begin_array: + if ((int)idx + 1 == unwind_idx) { + const char* head = reader.literal().data(); + if (!reader.next()) throw json::error{reader.error()}; + for (;;) { + if (reader.symbol() == json::token::symbol::end_array) + break; + + awk_value_t value; + + switch (reader.symbol()) { + case json::token::symbol::end: + case json::token::symbol::error: + case json::token::symbol::end_object: + case json::token::symbol::end_array: + assert(false); + case json::token::symbol::boolean: + make_number(reader.value<bool>() ? 1 : 0, &value); + break; + case json::token::symbol::integer: + case json::token::symbol::real: + make_number(reader.value<double>(), &value); + break; + case json::token::symbol::string: { + auto data = reader.value<std::string>(); + char* mem = (char*)gawk_malloc(data.size() + 1); + memcpy(mem, data.c_str(), data.size() + 1); + make_malloced_string(mem, data.size(), &value); + } + break; + case json::token::symbol::null: + value.val_type = AWK_UNDEFINED; + break; + case json::token::symbol::begin_array: + case json::token::symbol::begin_object: + value.val_type = AWK_UNDEFINED; + unwinded_values.push_back(value); + json::partial::skip(reader); + continue; + } + unwinded_values.push_back(value); + if (!reader.next()) throw json::error{reader.error()}; + } + assert(reader.symbol() == json::token::symbol::end_array); + const char* tail = reader.literal().end(); + if (!reader.next()) throw json::error{reader.error()}; + slice.size = std::distance(head, tail); + { + awk_value_t val; + auto ok = sym_update_scalar( + var_julength, + make_number(unwinded_values.size(), &val)); + assert(ok); (void)ok; + } + unwind_in_progress = true; + nunwinded = 0; + break; + } ``` I have explored a few concepts, but there are many more that were left off (e.g. backtracking, wrapping parsers, chunking). I'm also familiar with these topics and my assessment here would be the same: either there is no loss in the pull parser approach and they both perform well, or the push parser will perform significantly worse. ## A faster DOM tree There is another class of parsers that I haven't talked about. If parsing-to-DOM speed is the only relevant pursuit for this library, then it's failing too. It should be using destructive parsing techniques. Decoding strings can be performed in-place to put less pressure on allocators (and to skip several memory copies). I can expand on this topic if there is interest. ## Misc Some assorted issues and observations: - Boost.JSON serialization framework is non-existing. There's only one feature. The functions don't help to generate any serialized JSON value. Any value to be serialized must first be converted to the allocating variant-like class `json::value`. - `json::value::get_*()` functions break current convention for boundary checking versions of accessor functions in a variant class. - There is no `std::monostate` overload to initialize `json::value`. On a personal note, I'd prefer to see an explicit `json::null_t`. I don't like to conflate meaning of terms created for different purposes. - Documentation for the parser interface is pretty much lacking. Parameters are poorly explained and there are plenty of other questions that go unanswered. Can the handler pause the parsing loop by returning `false` w/o setting any error code (and how'd the stream be resumed)? Can the handler callbacks access parser methods such as `depth()`? Can the handler callbacks copy the parser object (this would be useful for backtracking)? - The code compiles with warnings. - The library offers far too little. The soundness of its design can't be proven. All it does is converting to/from a variant-like class and every other JSON-related use-case is left off. In the future, another library in the likes of QtXmlPatterns (but for JSON) will be built but this core -- Boost.JSON -- will prove unfit to build anything higher-level and a new core will have to be developed from the ground-up because current bad design choices. ## Appendix A: Strings through multiple buffers in pull parsers There are always compromises when it comes to designing programming abstractions. As for parsers, one of such compromises is a parser that never "fails" to consume input. Every input given is fully consumed. The idea here is to avoid "reparsing" old elements from the stream. For instance, one document may be received as the following two separate buffers: ``` "na\u00 EFve" ``` The parser may fail to consume the escape sequence thanks to missing characters and return `nread=3` for the first buffer. The performance argument in favour of a parser that doesn't fail is irrelevant. There is no performance gain by not reparsing 4 bytes. If your buffer is that small that you find yourself constantly reparsing elements then you have a problem way before the parsing level. The read syscall overhead would dominate. That's a pathological case. You must never design abstractions for a pathological case. I'll refrain from initiating any debate here on what'd constitute a pathological case for JSON parsers. I just want to make sure the reader has this in mind and he should be careful to not ask for every feature under the sun. He must carry a grain of doubt over whether a feature is really desired. In fact, the parser may not buffer, but [now the consumer does so](https://github.com/CPPAlliance/json/blob/fc7b1c6fd229e884df09fd45c64c61… (so much for a chunking parser). As for the topic on this section: can a pull parser support this case? The answer will be the same as before (to quote myself): > But as we've seen before, the only difference between pull and push > parsers is something else. Any features lateral to this classification > originate from different taxonomies. The enabling feature here is not the push interface. Rather it is the chosen set of generated events for the JSON token stream. If you change the notified events for the stream, you enable the same feature. For a pull parser, these are the events it'd have to provide (among other valid choices): - `string` (if non-split) - `string_run_begin` - `string_run` - `string_run_end` ## Appendix B: Why gawk? There are a few reasons why I've chosen a (GNU) AWK plug-in to illustrate the concepts presented in this review. First, I don't want to invent a new tool. Artificial examples could always be created to fabricate an argument. AWK is one of the classical UNIX tools. It's established and old. From [gawk manual](https://www.gnu.org/software/gawk/manual/html_node/History.html): > The original version of `awk` was written in 1977 at AT&T Bell > Laboratories. In 1985, a new version made the programming language more > powerful [...] This new version became widely available with Unix System > V Release 3.1 (1987). We're talking 40 years of history here. If the tool is established, that's one reason. Another reason why I've chosen AWK is that AWK has no JSON processing facilities, so it fills a gap in an existing tool. The third reason why I've chosen GNU AWK to create this plug-in is that gawk already has an extension mechanism. Therefore I don't have the freedom to modify the AWK processor to accommodate the JSON library idiosyncrasies. On the contrary, it's the JSON library the one to prove its flexibility. Now there's another question to answer here: why take MongoDB as inspiration to design the gap that would be filled in AWK (such as the `$unwind` operator)? And the answer will be the same. MongoDB is one of the JSON-oriented DBMS that got popular back in the NoSQL boom days. The end result tries to fit in the AWK's mindset and not the other way around. AWK is a tool designed for tabular data processing. JSON is in no way tabular, but its structure allows us to build a tabular view for the underlying data. There are two main variables in gawk to control how the fields are extracted: - `FS`: defines how to find the field _separators_. - `FPAT`: defines how to find the field _contents_. The plug-in just follows this trend and introduces a `JPAT` variable that also instructs how to find the field _contents_. `JPAT` is an array and each element has a [standard JSON Pointer](https://tools.ietf.org/html/rfc6901) expression that was designed exactly for this purpose. There's one very interesting fact about this outcome. The usage pattern here is removing from the library the step to process the stream (as the step that'd happen with the DOM approach) and moving much of the processing logic to be embedded in the parsing phase itself. That's a continuation from the trend we saw earlier about merging matching and decoding steps. It's also the same approach we'd use to build serious JSON processing tools such as [JMESPath](https://jmespath.org/) (some JMESPath expressions require a partial DOM, but it's doable to use a hybrid approach anyway as it has already been demonstrated in the `JUNWIND` code). ## Appendix C: Static decision trees with Boost.Hana The reader may be interested to know that the decision tree auxiliar to the parsing process developed for our (GNU) AWK plug-in is not only useful for AWK but to C++ programs as well. The decision tree strategy may even use Boost.Hana CT structures to fully unroll the code. It can be used to implement facilities such as: ```cpp using hana::literals::operator""_s; int foo; std::string bar; json::scanf(input, "{ foo: { bar: ? }, bar: ? }"_s, foo, bar); ``` That's also possible with Boost.JSON's current parser. But the following is not: ```cpp using hana::literals::operator""_s; Foo foo; std::string bar; json::scanf( input, "{ foo: { bar: ? }, bar: ? }"_s, [&foo](json::reader& reader) { // ... }, bar); ``` As it has been explained before, push parsers don't compose. And you aren't limited to root-level scanning. You should have `json::partial::scanf()` to act on subtrees too. A prototype for this idea can be found at <https://github.com/breese/trial.protocol/pull/43>. ## Review questions > Please be explicit about your decision (ACCEPT or REJECT). REJECT. > How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? I've stalled a project of mine for a few weeks just to participate in this review process. I think I've spent close to 50 hours. I wrote a JSON tool in Boost.JSON and the same tool under a different parser model to highlight important traits that were being dismissed in previous debates. I've gone through the documentation and source code to better understand some Boost.JSON details. I've also been involved in previous Boost.JSON debates in this very mailing list. > Are you knowledgeable about the problem domain? I've tested many JSON parser libraries in C++ to this point. In my last job I have leveraged a JSON (pull) parser to merge multiple validation layers into an one-pass operation and later leveraged Boost.Hana to automate the parser generation. Our API is JSON-based and we apply plenty of transformations (including DOM-based when unavoidable), some similar to the GNU AWK plug-in demonstrated here (e.g. synthesizing a new field on routed messages while DOM tree related costs are avoided). I've contributed a few algorithms and subtree parsing ideas back to the leveraged JSON (pull) parser. I offered the same composability ideas to Boost.JSON a few months back when the topic appeared here in this very mailing list. In the past, I've designed parsers in C++ -- pull and push parsers. I've played with some tools for parser generation such as re2c, gperf (gperf might not be really parsing, but it is related), and Boost.Xpressive. I've also experienced the pain of parsers that try to be too lightweight but ultimately backfire by moving not only performance costs back to the consumer but also greatly increasing complexity. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

4 6

[review][json] Boost.JSON review
by Peter Dimov 19 Sep '20

19 Sep '20

This is my review of Boost.JSON by Vinnie Falco and Krystian Stasiowski. First, a disclaimer: I have contributed to the library, mostly with design advice, occasionally to the implementation. Second, let's start with the end. I think that Boost.JSON should be ACCEPTED. All of its aspects are of Boost quality, its maintainers are qualified and responsive, the lack of a JSON library in Boost is frankly embarrassing, and the json::value type serves as a standard variant for scripting and transferring language-independent scalar and structured values, which opens many possibilities for further integration with future parts of the Boost ecosystem (I'll show an example of that later on.) To evaluate the library (I was already broadly, but not intimately, familiar with the structure and the interface), I started with the documentation, specifically with the Quick Look and Usage sections. It's very well written, and meets and exceeds the usual Boost level. I only have a few remarks to make. In Using Numbers, the documentation should explain more clearly and prominently that v.as_double() does not succeed when v contains an integer, but throws an exception. This is a common user expectation. Instead of focusing on number_cast, It should advertise value_to<double>(v) as the way to obtain a double from v, converting if necessary; and similarly, value_to<int>(v) as the way to obtain an int, range-checking if necessary. number_cast should be considered legacy at this point, and not featured. I understand that it offers an error_code& overload for those who don't want exceptions, but the throwing version is entirely superseded by value_to. In Parsing, the examples using parse_options look like this: parse_options opt; opt.allow_comments = true; opt.allow_trailing_commas = true; opt.allow_invalid_utf8 = true; value jv = parse( "[1,2,3,] // comment, extra comma ", storage_ptr(), opt ); That's fine and is indeed the C++11 standard-compatible way to do things. However, when designated initializers are available, such as on g++ or clang++, or on VS2019 with /std:c++latest, the above can be written as value jv = parse( "[1,2,3,] // comment, extra comma ", {}, { .allow_comments = true, .allow_invalid_commas = true, .allow_invalid_utf8 = true } ); and it might be useful to show this style too. In Value Conversion, Converting to Foreign Types, it's shown that defining a constructor customer::customer( value const& jv ); enables value_to<customer>(jv) to work. This is, in my opinion, a legacy mechanism made obsolete by tag_invoke and should not be supported. This example should be removed from the documentation, and only the tag_invoke way should be featured. And since we're on this page, it's odd that the StringLike requirement wants construction from (char*, std::size_t) - pointer to non-const characters. I don't think that any string type has such a constructor, they all take char const*. With the documentation carefully read (as in, quickly scanned), I proceeded to try to use the library. A previous reviewer (Reiner Deyke) had brought up the subject of CBOR parsing and serialization, and I had looked into CBOR as a format. It seemed regular and easy to parse and serialize, so I decided to write a CBOR serializer and parser for boost::json::value. How hard can that be, really? Not that hard. The serializer was quickly up and running, and it seemed quite performant: Serializing canada.json to CBOR: 1056200 bytes, 4840 us Serializing canada.json to JSON: 2306988 bytes, 13036 us (You can find the code at https://github.com/pdimov/boost_json_review/blob/master/boost_json_cbor.cpp, the serializer is the first 140 or so lines.) As far as using the library went, it was completely painless and straightforward. Next up, the parser. I decided to write it using the json::value interface, like a reference implementation. This, too, went well, and the parser was soon parsing, and even producing the same value as the one serialized. The performance, though... Parsing canada.json from JSON: 10548 us Parsing canada.json from CBOR: 33941 us, successful roundtrip This wasn't good. Switching to a binary format such as CBOR is supposed to be faster, not 3.4 times slower! Before you say "well your parser is written like you were a college student who was taught Java", be aware that I actually refactored the parser a number of times; sometimes it was written in one style, sometimes in another, functions went from being hand-inlined to extracted and back a few times, but none of that made a dent on those 34ms. To find out where the time was going, I looked into way more detail I needed to. For instance, I saw that assigning f.ex. 1.0 to a default-constructed json::value executes much more code than it needs to, and makes non-inlined calls into libboost_json. One would expect this to take one check and branch (do we need to deallocate anything? no), and two assignments (kind = kind_double; dbl_ = 1.0). Turns out that the efficient way to assign 1.0 is not `v = 1.0;`, but `v.emplace_double() = 1.0;`. I of course replaced the assignments with this supposedly efficient form, and it of course made no difference at all. I then in desperation actually removed all the assignments. And it barely made any difference. At this point I decided that the json::value interface is not the right fit for a performant parser, and switched to using boost::json::value_stack. This is what Boost.JSON's parser itself uses, so if that's not fast, well, I don't know what will be. Updating the parser to use value_stack was basically trivial: https://github.com/pdimov/boost_json_review/commit/7aa8d2dc8c706c3f4204d6fe… and it worked. The performance was what I expected: Parsing canada.json from JSON: 10044 us Parsing canada.json from CBOR: 6332 us, successful roundtrip (You can find the value_stack parser at https://github.com/pdimov/boost_json_review/blob/master/boost_json_cbor_st.… and the results at https://github.com/pdimov/boost_json_review/blob/master/boost_json_cbor_st.….) (Since now changes to the parser code actually affected performance, I added two optimizations to the array parsing - a fast path for arrays containing only doubles, and a fast path for arrays containing only integers.) Is value hopeless for parsing, then? I went back to the other parser. This is how the part that parses objects looks like, with the irrelevant parts omitted: boost::json::object & o = v.emplace_object(); o.reserve( n ); for( std::size_t i = 0; i < n; ++i ) { // key string boost::json::string_view sv( ... ); // value boost::json::value w( v.storage() ); first = parse_cbor_value( first, last, w ); o.insert( boost::json::key_value_pair( sv, std::move( w ) ) ); } The reason I use o.insert here is that I wanted the CBOR parser to match the behavior of the JSON parser with respect to key order and duplicate keys. The JSON parser preserves key order, which is both user-friendly and better from a security perspective (observing key order may leak the seed of the hash function.) It also handles duplicates in an unspecified manner. Well, whatever that unspecified manner was, I wanted to do the same, and using `insert` looked like the way to do it. There however was no `insert` taking a string_view and a value, so I had to create a key_value_pair. There was `insert_or_assign` that did take a string_view and a value, but it overwrites duplicates, and I didn't want that. I consulted Vinnie Falco about the lack of `insert(string_view, value)`, and he pointed me at `emplace`. This sounded exactly like what my hypothetical `insert` would do. However, hearing `emplace` gave me an idea. In the same way `v.emplace_object()` gives me `object&`, `o.emplace(sv)` could have given me `value&`, which I could then pass directly to `parse_cbor_value`: first = parse_cbor_value( first, last, o.emplace(sv) ); I shared this brilliant observation with Vinnie, and he replied "obj[sv]". obj[sv] indeed. Sometimes we forget that C++98 did have a useful feature or two. This doesn't exactly work as I wanted it to, because it neither guarantees insertion order, nor has the "right" duplicate handling. Nevertheless, I did make the change: https://github.com/pdimov/boost_json_review/commit/e6baf8f1ce81966534ac93c5… and guess what? Parsing canada.json from JSON: 10261 us Parsing canada.json from CBOR: 6761 us, successful roundtrip So the problem the entire time was that one single line: o.insert( boost::json::key_value_pair( sv, std::move( w ) ) ); I haven't looked into it, but I suspect that it for some reason makes a copy of `w`, even though it's passed using `std::move` and uses the right `storage_ptr`. Oh well. At least it works now. So, there is nothing that much wrong with the `value` interface, and it's possible to build values the straightforward way, instead of using a value_stack, without significant loss in performance. These CBOR parsers are entirely functional, and only have the following limitations: * Binary strings are not supported (as they're not representable in json::value); * Infinite sequences are not supported (because I was too lazy); * 32 bit platforms need to check the string/array/object sizes for possible size_t overflow (because I was way too lazy.) I had also looked at, and tried, the value conversion interface, in the course of developing the examples of an unreleased library of mine, Describe. The value_from example is https://pdimov.github.io/describe/doc/html/describe.html#example_to_json value_to is at https://pdimov.github.io/describe/doc/html/describe.html#example_from_json and a simple JSON-RPC example is at https://pdimov.github.io/describe/doc/html/describe.html#example_json_rpc These all worked without any trouble, except I had to link with Boost.Container for one of them, which didn't seem necessary. They are also a good illustration of the possibilities that having a standard json::value type presents, in terms of further library development. (One could f.ex. imagine a Boost.Script interpreter that uses json::value as its data type, and can be used to script C++ code.) In conclusion, the library works, is well documented, and should be ACCEPTED. I have no acceptance conditions. Obviously, the performance problem concerning object::insert needs to be addressed, and more generally, the value interface needs a bit more performance scrutiny because it's not currently exercised by the benchmarks, but I trust that this will be done. Solid work, thanks to the authors for their submission, and thank you for reading this far.

2 1

Github CI testing with appveyor and travis
by Edward Diener 19 Sep '20

19 Sep '20

I can not seem to get appveyor or travis CI to test the repositories of which I am the maintainer, PP, VMD, and TTI, any more. Normally I would not care much about the CI testing, but the fact that they seem to have stopped wortking completely, or maybe just stopped sending me back results, bothers me. All three have appropriate .yml files. Have these CI services stopped working ? How do I integrate them again with these Boost libraries ?

3 8

[JSON][review] a small review of boost.json
by Julien Blanc 19 Sep '20

19 Sep '20

Hi, Here's my small review of boost json. ## Are you knowledgeable about the problem domain? I've written a json library (for reference: https://github.com/Julien-Blanc-tgcm/jbc-json ) which i used as playground / experiments. I guess this makes me knowledgeable enough of the domain. ## What is your evaluation of the design? I think the library is well designed, although it has several shortcomings. These shortcomings may not alter general usage of the library (with main target seeming to be REST api over http), but render it useless in specific cases. For me, a json library consists of three independant parts and some glue: * a parser * a type for representing values (usually a variant) * a printer (serializer) ### The parser In boost.json, the separation between the parser and seems neat enough (ie, you can use the parser without the json::value type). However, it resides in a <detail> header, which would indicate that it is not an expected use case. I believe it should be. The callbacks of the parser (push parser) are not documented. I'm a bit puzzled by what the on_number_part does, and how it fits with the on_int64/on_double callbacks, for example. The parser is an incremental push parser. However, it seems to expect to be feeded with partial json documents, but not consecutive json documents. I could not find a way to make : auto v = p.write(R"json({"foo":1}{"bar":2})json"); return 9. I may have missed something, but this use case is IMHO important to address. Since the only way to know that a json document has ended is to parse it, the parser should provide an option to parse a stream containing multiple consecutive json documents (ie, stopping without error at the end of each document). A common use case for this is JSON notifications received via raw sockets, so no envelope may be used to isolate JSON documents. ### The value type The value type is a variant, the kind that you would expect from a json library. Most of the interface uses string_view, which is a very good thing (the fact that boost.json uses another string type internally has not been an issue in my tests, due to the usage of string_view). It lacks visitation, though (IIRC there’s an open issue for this). The fact that this value type has been highly optimized is the great strength of this library. #### objects The object interface relies on the [] operator, which incurs the same shortcomings as with std::map : auto v = foo["bar"]; // will silently create bar if it does not exists Typos in keys had always been a source of hard to find bugs, i wished there was an option to disable operator[] and force the use of find. The library has no support for object with duplicate keys, which also are valid json. This, however, can be worked around by using the parser callbacks and not the variant (but that makes it difficult to produce such documents, cf later). Whether the order of the keys is kept by the object structure or not does not appear in the documentation. From my small testing, it seems that it is the case, but the api does not offer any interface to add elements at specific position, so i would assume it is not guaranted. The json specification, AFAIR, does not forbid to rely on a specific order of the keys. Some serialization libraries do expect the keys to be in a specific order. #### numbers Having two number types can lead to unexpected results : auto v = boost::json::parse("{\"foo\":1,\"bar\":2.0}"); std::cout << v.as_object()["bar"].as_double() << std::endl; // ok std::cout << " " << v.as_object()["foo"].as_double(); // asserts It is unexpected, because several json libraries will never output “2E0” or “2.0” for the value “2”, but a plain “2”. It means that whenever you expect a double value, you also have to check for the possibility that it has been parsed as an integer. The to_double function should silently convert integers to their double equivalent whenever it is possible. * as has already been noted by others, the number precision is hardcoded to IEE754 or 64bits integer. This is seldom an issue, since it is the case with most implementations. #### The printer The printer is not usable without the value item. I would expect it to be (producing json without resorting to an intermediate representation). Apart from this, it supports incremental printing, which is what is expected. It produces a strange representation for numbers, but it is conforming to the JSON specification. Because it is tied to the json::value, it cannot produce anything that cannot be represented by a json::value. This is an issue that should be addressed. ## What is your evaluation of the implementation? I did not have a thorough look into the implementation details. From what i have seen, the implementation looks fine. A parser is usually a landmine for security exposures, and would need a very careful review which i cannot do. IIRC the authors plan on having an independant audit on the library, which is a good thing. There is also fuzzing and tests, so we can expect that this point is correctly being taken care of. The rest of the code looks fine, easy to navigate into. ## What is your evaluation of the documentation? Very good. Easy to use, complete. There is some missing information, but they all seems related to design decision that have been taken implicitly (already discussed in design section). An example on using the parser on standalone mode would be a very welcome addition. Another thing that the doc should state clearly : boost.json is **not** a JSON (ECMA-404) library, but rather an I-JSON (RFC 7493) library with some extensions. ## What is your evaluation of the potential usefulness of the library? Very useful. While it does not address all use cases (and does not try to), it addresses what is probable the *most common* case. As JSON is very widespread, i expect this library to find a large audience, because it combines ease of use and performance. ## Did you try to use the library? With what compiler? Did you have any problems? I tried to use it on a small toy application, on a debian stable system. The main target seems to be to use the library with boost. I ran into several issues when trying to use the standalone version. The first one was easy to address, and due to gcc 8.3 lacking c++17 support. A patch was submitted, and merged quickly. The second one was incompatibilites between standalone asio bringing boost headers (because boost is installed on my machine) and json redefining them (because of standalone mode), resulting in multiple defenitions of throw_exception. I'm not sure yet if i should file this to boost.json, asio library, or asio debian package, or if it is just a missing define on my part. At that point, i switched to boost json, which fixed the issues i had. ## How much effort did you put into your evaluation? I'd say around 10 hours reading, testing and playing, including writing of the review. ## Do you think the library should be accepted as a Boost library? I think the library should be ACCEPTED. There are shortcomings in the library, it does not address every use case in the world, but it does a very good job at what it is designed to do. It is easy to use, performant, and it addresses a very widespread use case, so the pros clearly outweighs the cons. Regards, Julien

3 3

[preprocessor] Dropping support for compilers that do not implement variadic macros
by Edward Diener 18 Sep '20

18 Sep '20

In lieu with Boost's decision regarding dropping support for C++03 compilation, I would like to drop support in the preprocessor library for preprocessors which do not implement variadic macros. Variadic macros were added in the C++11 standard, although a number of compilers supported them even before the official C++ standard. I will of course keep the same macro APIs, although deprecating non-variadic macro forms when alternate variadic macro forms exist. This will simplify Boost PP. Ideally, once Boost PP supports only preprocessors which implement variadic macros, Boost VMD can be added to Boost PP, for anyone who wants to use its functionality, and Boost VMD can then be retired.

6 25

[JSON][review] Design: what is expected of a "JSON library"?
by Andrzej Krzemienski 18 Sep '20

18 Sep '20

Hi Everyone, This is not a complete Boost Review yet. In this email I wanted to discuss the design goals of the library. The point that I would like to raise is the tension between having relatively small types (int64_t, uint64_t, double) represent numbers in json::value on the one hand, and ECMA specification allowing arbitrarily big/precise numbers in JSON format on the other. Can I expect of a JSON library that when it converts a JSON contents into internal representation and then back to JSON contents, I should get the same contents (moduo white space)? This would be possible if the internal representation of JSON numbers was an arbitrary-precision decimal type or a string. But when we need to squeeze any number into 24 bits, we will soon get to the point when integer number `100000000000000000000001` after the experiment gets changed to `1E23`. Is this acceptable for a JSON library? But maybe it is not a valid goal? Maybe the goal of the JSON format is to have objects already created in internal representation converted to text and then back to objects? (assuming the recipient program is run on the same environment as the sender (no differences in word size or maximum int representation.) That is, as long as you agree to the constraints of json::value, whatever you manage to put inside, we guarantee that you get the same value when you serialize it and then parse it back. Boost.JSON does this nicely. In that other view, if I have objects of types `boost::multiprecision::cpp_int` my only option is to pass them as strings in JSON protocol. But I can pass any number as string anyway, so what is the use of numbers in JSON format? Uness it is just practical: you can choose to use numbers and then internal representations of JSON may be smaller. Do you get the concern that I am seeing? I mean I have used JSON libraries before, and this has never been a practical problem. But Boost Review puts the bar high for the libraries, so I guess this question should be answered: what guarantees can a JSON library give us with respect to accuracy of numbers? Regards, &rzej;

6 11

Re: [boost] [JSON[review] Andrzej's review
by Peter Dimov 17 Sep '20

17 Sep '20

> Vinnie Falco wrote: > > > Just open an issue and explain how you think self-swap, self-move, and > > self-assignment should work and I will make the changes. > > They should be no-ops. More specifically, self-swap should be a no-op, and assignments should be equivalent to: T& operator=( T const& rhs ) { T(rhs).swap(*this); return *this; } T& operator=( T&& rhs ) { T(std::move(rhs)).swap(*this); return *this; } This is important for classes such as json::value, object, array, where *this may own rhs, so it's important not to destroy rhs too early. E.g. v = v.at(0); v = std::move(v.at(0)); a = a.at(0).as_array(); a = std::move(a.at(0)).as_array(); o = o.at("key").as_object(); o = std::move(o.at("key").as_object()); This is not self-assignment, but it has the same lifetime pitfalls - if you destroy the old contents of *this, rhs is invalidated, so you can no longer copy (or move) it.

2 1

Interactive mail
by SIDDHARTH PANDEY 17 Sep '20

17 Sep '20

Hello everyone, myself Siddharth Pandey, a sophomore at Indian Institute of Information Technology Sri City, India. I love to do Competitive Programming and have a keen interest in Open Source Contribution. I have a strong foundation on C,C++ and some about Python & Java. Also I am trying to explore the field of Data Science & Machine learning. For more information do visit my Portfolio website https://siddharth25pandey.github.io/ I want to contribute to the Boost Organisation but I am quite confused how to start with. It will be really helpful if any mentor can guide me how to start Contributing to get a great learning from such a highly reputed organization. Thanks & Regards Siddharth Pandey

4 3

Boost Log 1.65.1 Linking Issue
by Karmethia Thompson 16 Sep '20

16 Sep '20

Good morning, I am trying to create a logger that uses Boost Log. I was successful getting my code to compile with 1.63.0, so I know that I am not too far off of the mark. cmake/make throws a linking issues whenever I attempt to create a sink: typedef sinks::synchronous_sink< sinks::text_ostream_backend > text_sink; boost::shared_ptr< text_sink > sink = boost::make_shared< text_sink >(); or create file sink logging::add_file_log ( keywords::file_name = log_specs.log_file, keywords::rotation_size = 10 * 1024 * 1024, keywords::time_based_rotation = sinks::file::rotation_at_time_point(0, 0, 0), keywords::filter = min_severity || severity >= file_severity, keywords::format = ( expr::stream << expr::format_date_time<boost::posix_time::ptime>("TimeStamp", "%Y-%m-%d_%H:%M:%S.%f") << ": [" << severity << "]" << expr::smessage ), keywords::auto_flush = true //flush to file.. ); My code will compile 95% and then produce the following: CMakeFiles/main.dir/src/Logger.cpp.o: In function `boost::enable_if_c<(boost::log::v2_mt_posix::aux::is_character_type<wchar_t>::value&&boost::log::v2_mt_posix::aux::is_character_type<char>::value)&&((sizeof (wchar_t))!=(sizeof (char))), bool>::type boost::log::v2_mt_posix::aux::code_convert<wchar_t, char, std::char_traits<char>, std::allocator<char> >(wchar_t const*, unsigned long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, unsigned long, std::locale const&)': Logger.cpp:(.text._ZN5boost3log11v2_mt_posix3aux12code_convertIwcSt11char_traitsIcESaIcEEENS_11enable_if_cIXaaaasrNS2_17is_character_typeIT_EE5valuesrNS8_IT0_EE5valuenestS9_stSB_EbE4typeEPKS9_mRNSt7__cxx1112basic_stringISB_T1_T2_EEmRKSt6locale[_ZN5boost3log11v2_mt_posix3aux12code_convertIwcSt11char_traitsIcESaIcEEENS_11enable_if_cIXaaaasrNS2_17is_character_typeIT_EE5valuesrNS8_IT0_EE5valuenestS9_stSB_EbE4typeEPKS9_mRNSt7__cxx1112basic_stringISB_T1_T2_EEmRKSt6locale]+0x37): undefined reference to `boost::log::v2_mt_posix::aux::code_convert_impl(wchar_t const*, unsigned long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, unsigned long, std::locale const&)' CMakeFiles/main.dir/src/Logger.cpp.o: In function `void boost::log::v2_mt_posix::sinks::basic_formatting_sink_frontend<char>::feed_record<boost::recursive_mutex, boost::log::v2_mt_posix::sinks::basic_text_ostream_backend<char> >(boost::log::v2_mt_posix::record_view const&, boost::recursive_mutex&, boost::log::v2_mt_posix::sinks::basic_text_ostream_backend<char>&)': Logger.cpp:(.text._ZN5boost3log11v2_mt_posix5sinks30basic_formatting_sink_frontendIcE11feed_recordINS_15recursive_mutexENS2_26basic_text_ostream_backendIcEEEEvRKNS1_11record_viewERT_RT0_[_ZN5boost3log11v2_mt_posix5sinks30basic_formatting_sink_frontendIcE11feed_recordINS_15recursive_mutexENS2_26basic_text_ostream_backendIcEEEEvRKNS1_11record_viewERT_RT0_]+0x141): undefined reference to `boost::log::v2_mt_posix::sinks::basic_text_ostream_backend<char>::consume(boost::log::v2_mt_posix::record_view const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' CMakeFiles/main.dir/src/Logger.cpp.o: In function `void boost::log::v2_mt_posix::sinks::basic_formatting_sink_frontend<char>::feed_record<boost::recursive_mutex, boost::log::v2_mt_posix::sinks::text_file_backend>(boost::log::v2_mt_posix::record_view const&, boost::recursive_mutex&, boost::log::v2_mt_posix::sinks::text_file_backend&)': Logger.cpp:(.text._ZN5boost3log11v2_mt_posix5sinks30basic_formatting_sink_frontendIcE11feed_recordINS_15recursive_mutexENS2_17text_file_backendEEEvRKNS1_11record_viewERT_RT0_[_ZN5boost3log11v2_mt_posix5sinks30basic_formatting_sink_frontendIcE11feed_recordINS_15recursive_mutexENS2_17text_file_backendEEEvRKNS1_11record_viewERT_RT0_]+0x141): undefined reference to `boost::log::v2_mt_posix::sinks::text_file_backend::consume(boost::log::v2_mt_posix::record_view const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' CMakeFiles/main.dir/src/Logger.cpp.o: In function `void boost::log::v2_mt_posix::sinks::basic_formatting_sink_frontend<char>::feed_record<boost::log::v2_mt_posix::aux::fake_mutex, boost::log::v2_mt_posix::sinks::basic_text_ostream_backend<char> >(boost::log::v2_mt_posix::record_view const&, boost::log::v2_mt_posix::aux::fake_mutex&, boost::log::v2_mt_posix::sinks::basic_text_ostream_backend<char>&)': Logger.cpp:(.text._ZN5boost3log11v2_mt_posix5sinks30basic_formatting_sink_frontendIcE11feed_recordINS1_3aux10fake_mutexENS2_26basic_text_ostream_backendIcEEEEvRKNS1_11record_viewERT_RT0_[_ZN5boost3log11v2_mt_posix5sinks30basic_formatting_sink_frontendIcE11feed_recordINS1_3aux10fake_mutexENS2_26basic_text_ostream_backendIcEEEEvRKNS1_11record_viewERT_RT0_]+0x141): undefined reference to `boost::log::v2_mt_posix::sinks::basic_text_ostream_backend<char>::consume(boost::log::v2_mt_posix::record_view const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' CMakeFiles/main.dir/src/Logger.cpp.o: In function `void boost::log::v2_mt_posix::sinks::basic_formatting_sink_frontend<char>::feed_record<boost::log::v2_mt_posix::aux::fake_mutex, boost::log::v2_mt_posix::sinks::text_file_backend>(boost::log::v2_mt_posix::record_view const&, boost::log::v2_mt_posix::aux::fake_mutex&, boost::log::v2_mt_posix::sinks::text_file_backend&)': Logger.cpp:(.text._ZN5boost3log11v2_mt_posix5sinks30basic_formatting_sink_frontendIcE11feed_recordINS1_3aux10fake_mutexENS2_17text_file_backendEEEvRKNS1_11record_viewERT_RT0_[_ZN5boost3log11v2_mt_posix5sinks30basic_formatting_sink_frontendIcE11feed_recordINS1_3aux10fake_mutexENS2_17text_file_backendEEEvRKNS1_11record_viewERT_RT0_]+0x141): undefined reference to `boost::log::v2_mt_posix::sinks::text_file_backend::consume(boost::log::v2_mt_posix::record_view const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' collect2: error: ld returned 1 exit status make[2]: *** [main] Error 1 make[1]: *** [CMakeFiles/main.dir/all] Error 2 Can someone please help? I have tried everything from trying to dynamically and statically link. I've added both "log" and "log_setup" to the find_packages in cmake and have also explicitly specified the locations of those libraries as well. Please let me know if there is anything else to try. Thanks -- Karmethia Thompson Applied Mathematics, PhD

4 6

Re: [boost] Boost Log 1.65.1 Linking Issue
by Peter Dimov 15 Sep '20

15 Sep '20

Although, now that I think of it, the shown CMakeLists.txt file didn't use imported targets, so perhaps the order of libraries is literal and putting log_setup before log may indeed solve things. -----Original Message----- From: Peter Dimov Sent: Tuesday, September 15, 2020 20:28 To: boost(a)lists.boost.org Subject: Re: [boost] Boost Log 1.65.1 Linking Issue Andrey Semashev wrote: > I'm not sure, but I think the above would generate incorrect order of > libraries in the linker command line. You need to ensure that boost_log > comes after boost_log_setup, and their dependencies come after still. CMake automatically orders libraries so that the dependencies come after. Unfortunately, FindBoost has a bug and declares log as depending on log_setup, rather than vice versa. https://github.com/Kitware/CMake/blob/bdcde7762c71cd27fcba6dc1a3efe12fa7a09… No matter how you order the libraries in target_link_libraries, the order between these two will never be correct. Not sure if this is the problem here though.

1 0

[Math] Adding prime sieves - design discussion
by John Maddock 15 Sep '20

15 Sep '20

Just a heads up, that Boost.Math has an open PR for adding prime sieves, and there is an ongoing design discussion on interface etc. If anyone has any strong feelings on the matter, usage requirements etc, then comments would be most welcome. See https://github.com/boostorg/math/pull/400. Many thanks, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

[JSON][review] Some early feedback
by Andrzej Krzemienski 15 Sep '20

15 Sep '20

Hi Everyone, The formal review of Boost.JSON has not started yet, but I thought I could offer some feedback from my playing with the library earlier in the process. Documentation --------------- Very well written. It makes it easy to grasp quickly the spirit and the potential of the library, and the reference section makes it easy to navigate through the features and their interfaces. Some minor issues: 1. Section "Using Numbers" is missing content. 2. Description of storage_ptr's destructor and move constructor is missing noexcept. 3. Docs in a couple of places call `storage_ptr` a "smart pointer container". Is it intentional? "Container" has a very specific meaning in C++. Design. ----------- It is generally sound, and well explained in the rationale. Here are a couple of minor remarks. 1. The usage of `nullptr` for null values. `nullptr` has been introduced to mean "a pointer with null value" and is only used in the standard library for smart pointers, with an ignoble exception of `std::function<>`. Using it for `json::value` is not an obvious choice for me. On the other hand, we do not have a universal type representing a missing value. A library could provide its own `json::null`, although I am not sure if this is an ideal solution either. 2. Why is json::value Semiregular rather than Regular? Equality comparison has a natural interpretation and application for checking if the produced JSON looks exactly as expected, or for checking if some two subtrees are the same. Is it because of efficiency issues with json::object comparison? 3. The library is using a custom string type. We get a rationale for this, and I accept it. But there are still some concerns about it that I would like to mention. 3.1. It is not the first library reviewed his year to have a custom type with std::string-compatible interface. It looks like the idea of having a "vocabulary" string type is unrealistic. If this should be the case, maybe we need a concept specifying what a string-compatible type should provide. It is obvious that json::string does not literally provide the same interface as std::string. Nor does anyone expect 100% compatibility. 3.2. Docs say that json::string is like std::string *except for* a number of things. For instance it does not provide the controversial assignment from `char`. Given that you are "fixing" the shortcomings of std::string, maybe it is an opportunity to fix other things in it also. For instance, std::string has been criticised for having too big an interface. That it mixes an iterator-based interface with an indexed-based one. Myb functions like `find_first_not_of()` are not necessary, given that users can use all sorts of iterator-based algorithms? 3.3. The rationale for json::string says that inisializer_list constructor is unnecessary, because string literal can always be used instead. This does not take into account that initializer_list does not necessarily operate on constant values. There is no concise substitute for: ``` std::string arrange(char a, char b, char c) { return {c, a, b, c}; } ``` I would not miss this construction much, I guess, but I would expect this to be mentioned in the rationale. 4. One thing one often expects of a JSON library is to be able to pretty-print a JSON document. The docs give an example how to do it, but the library does not provide this feature out of the box. Is pretty-printing not compatible with the design goals of the library? Implementation -------------- I didn't look much at it yet, but here is something I found. 1. `json::string_view` is convertible from `std::stirng`, but it is not convertible from `std::string_view`. I think there is no harm in enabling this conversion, and it seems useful. 2. The following piece of code ``` json::value v = 50.0; std::cout << json::serialize(v); ``` oututs: 5E1 which is technically compliant with JSON specification, but quite surprising. Is there a reason for this? Can serialization be controlled to output 50.0 or 50? 3. It is confusing for me to see member function serializer::read. I would think that the action that a serializer does is *write* rather than read. Am I missing something? 4. I really appreciate the ability to use the library in header-only mode with <boost/json/src.hpp>. This makes library testing much simpler. Regards, &rzej;

7 10

[json][review] A review from an embedded perspective
by Brooks Prumo 15 Sep '20

15 Sep '20

Hi everyone, this is my first time mailing the Boost developer list, and also submitting a review. Thank you in advance for understanding any issues it may have! I'm writing to review Boost JSON. I've been using it very lightly for the last week or so. My usage has been exclusively on embedded MCUs (ARM Cortex M4, compiling with ARM GCC 9 with C++17), which I'm guessing hasn't been the common case so far. Here's a list of things that matter a lot to me: - Compile from source. Boost JSON passes. - No exceptions. C++ exceptions are turned off, so all libraries I use must support not throwing. Boost JSON passes. - No iostreams/locale. If a library uses iostreams, my binary jumps ~220 KB which is a deal breaker. Boost JSON passes. - Binary size matters a lot, since onboard Flash is very limited. I am using a "big" MCU, and that means my whole binary must be under ~512 KB. Right now Boost JSON is not great. In doing a simple serialization and parse, the library itself adds ~58 KB to my .text section. This is OK for now, but surprisingly big. I know the team is aware of this and has some ideas to reduce the binary size. I will likely need those fixes to actually port my app to Boost JSON. - Control over the sizes of any "large" stack buffers. Boost JSON passes. - No external dependencies that do not meet the above requirements. Boost JSON passes. With this, Boost JSON is an ACCEPT from me. THe biggest reason for me is that the API is nice to work with. I started off with Nlohmann, but the binary size was too big due to iostreams. I'm currently using RapidJSON, and it's definitely not easy to use. In my app, JSON is not in the hot path. I want a library that is easy to use and meets my requirements above. I greatly appreciate being able to use a modern C++ library. And answers to the other questions: - What is your evaluation of the design? So far so good. I do not have complicated JSON uses though. - What is your evaluation of the implementation? I've only looked at the implementation when it comes to binary size. - What is your evaluation of the documentation? Documentation is nice. I personally would enjoy more examples, as that is how I commonly learn new libraries. - What is your evaluation of the potential usefulness of the library? HUGE! I haven't come across another modern C++ JSON library that'll work in the embedded space I live in. It's really exciting! - Did you try to use the library? With which compiler(s)? Did you have any problems? Yep! I used ARM GCC 9.2.1 with C++17. No issues with compilation. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I'd say my evaluation is "initial". I've used it in a way that mimics my real usage, but haven't used many aspects of the whole library. - Are you knowledgeable about the problem domain? Minimally. Just basic JSON knowledge. Thank you! Brooks

3 2

[preprocessor] Appveyor weirdness
by Edward Diener 14 Sep '20

14 Sep '20

In my appveyor.yml file for preprocessor one of the b2 command lines for a test run uses an explicit alias for the target. When run in appveyor.yml I get the messages: notice: could not find main target preprocessor_limits notice: assuming it is a name of file to create . and don't know how to make <e>preprocessor_limits Yet when I run the same test locally using the preprocessor_limits target, everything works fine. Is Appveyor somehow different when running Boost Build tests than when I run it locally ?

1 0

No doc for qvm in 1.74 distro
by Edward Diener 12 Sep '20

12 Sep '20

There is no doc for the qvm library in the 1.74 distro.

2 1

[JSON][review] Should there be an equality operator/function?
by Hadriel Kaplan 12 Sep '20

12 Sep '20

Howdy, I’ve been testing Boost.JSON in preparation for writing a review, and one thing that I found surprising might be better discussed in a separate thread, so here goes… There’s currently no comparison function or operator to compare one json::value with another. While I appreciate that a deep comparison isn’t cheap - it’s O(N) for the average case but O(N^2) in the worst case I believe - I still think it’ something a JSON-based container value type should have out-of-the-box. It’s something other popular JSON libraries offer; usually with equality operators, although a named function would be ok too if that was required instead. I hit the lack of it almost immediately, since test code/assertions frequently check equality. I’m not sure how frequently it’s used for run-time code in general, however. -hadriel

1 1

Looking for a review manager for Real
by Damian Vicino 10 Sep '20

10 Sep '20

Hi, GSOC finished and we are almost-ready for proposing to review a new library, Real. We are looking for a volunteer to be a review manager for it. Best regards, Damian

9 15

Do I need to use boost::mutex in deadline_timer?
by Jupiter 10 Sep '20

10 Sep '20

Hi, I used boost::asio::io_service for a single thread implementation but with multiple boost::asio::deadline_timer objects, because it is a single thread, I don't think I need to use boost::mutex to lock and unlock tasks running by deadline_timer, am I wrong about it? Thank you. Kind regards, jupiter

3 4

Re: [boost] boost.real
by Kostas Savvidis 09 Sep '20

09 Sep '20

Hi Damian, Laouen, I have been able to compile the test programs with your library after making some simple changes. The patch is below the message. However the example program from your documentation still does not compile, unless I comment out some lines - you can see the listing below. I ran a tricky calculation which is from the Aberth book, your program is able to give the answer and moreover the true value is indeed between the upper and lower bounds that your program gives. This is good! The conclusion is that your library can do useful work, but it is very limited in capability. No special functions, trig is there but not working well, and no simple way to interface with linear algebra. I may want to use it at some point, but I would need at least the ability to cast int and double to your boost::real::real type, because as it is now, the only way to import numbers into your software seems to be through std::string. Finally what seem to be some bugs: 1) unsigned int real::maximum_precision = 10; // error: specializing member 'boost::real::real<int>::maximum_precision' requires 'template<>' syntax 2) auto it = e.cbegin(); // error: 'using real = class boost::real::real<int>' {aka 'class boost::real::real<int>'} has no member named 'cbegin' 3) real::sin(f) // enters infinite loop 4) real c = (std::string)"0.999999"; prints: c: [0.99999899999999999999999999999999999999999999999999999999999999999999999999999999999999999933600778729, 0.99999899999999999999999999999999999999999999999999999999999999999999999999999999999999999982691714296] as far as i can see the interval is incorrect ! Best Regards, Kostas ============================================================================================= diff -r -u real.orig/integer_number.hpp real/integer_number.hpp --- real.orig/integer_number.hpp 2020-09-07 16:22:04.000000000 +0300 +++ real/integer_number.hpp 2020-09-08 14:11:22.000000000 +0300 @@ -103,7 +103,8 @@ } // this function always expects (*this) to bigger than other, so if borrow is not zero at the end // there should be error - if(borrow != 0); + if(borrow != 0) + ; //throw subtraction_number_required_lower_exception(); diff -r -u real.orig/real_rational.hpp real/real_rational.hpp --- real.orig/real_rational.hpp 2020-09-07 16:22:04.000000000 +0300 +++ real/real_rational.hpp 2020-09-08 11:59:51.000000000 +0300 @@ -262,7 +262,7 @@ // constructor to generate get number from string constexpr explicit real_rational(std::string_view num){ // searching for "/" in string - size_t pos; + size_t pos=0; bool found = false; std::string_view num1, num2; pos = num.size(); ============================================================================================= #include <iostream> #include <string> #include <real/real.hpp> using real = boost::real::real<int>; //unsigned int real::maximum_precision = 10; //unsigned int real_algorithm::maximum_precision = 10; int main() { real c = (std::string)"0.999999"; real d = (std::string)"0.999999"; real e = c + d; std::cout << "c: " << c << std::endl; std::cout << "d: " << d << std::endl; std::cout << "e=c+d: " << e << std::endl; // ANSWER IS WRONG ??!!! // for(auto it = e.cbegin(); it != e.cend(); ++it) { // std::cout << "e iteration " << it.approximation_interval << std::endl; // } real g = (std::string)"0.999998"; std::cout << "g: " << g << std::endl; if (g < d) { std::cout << "g < d --> true" << std::endl; } else { std::cout << "g < d --> false" << std::endl; } real h = d - g; std::cout << "h=d-g: " << h << std::endl; std::cout << "h++ is: " << h+real("1.0") << std::endl; { // Example from Aberth 1992, Precise Computation Using Range Arithmetic real a("77617.0"); real b("33096.0"); std::cout << "\n\n" << "a: " << a << std::endl; std::cout << "b: " << b << std::endl; real f = real("333.75")*b*b*b*b*b*b + a*a*(real("11.0")*a*a*b*b-b*b*b*b*b*b - real("121.0")*b*b*b*b-real("2.0")) + real("5.5")*b*b*b*b*b*b*b*b + a/(real("2.0")*b); // should be -0.827396 std::cout << "f: " << f << std::endl; //std::cout << "sin(f): " << real::sin(f) << std::endl; // doesn't come out of the loop } return 0; }

2 1

[LEAF] Review Results
by Michael Caisse 09 Sep '20

09 Sep '20

I want to thank Emil for his patience for the publishing of the review results as life got in my way. Thank you Emil for submitting LEAF to be reviewed for inclusion into Boost. As an already-Boost-author, you knew what you were getting into and continued into the process. I also want to thank you for once again pushing our thoughts on error handling. -------- Result -------- This is the part everybody scrolls to the bottom to read, so let’s just put it at the top. Boost.LEAF is ACCEPTED into Boost. After the following modifications are made to the library, the repository can be transitioned to Boost for inclusion into the next release (with the release cycle timing constraints): Specify the TLS requirement sooner in the documentation. Optional usage of Boost.Config to perform all of the Boost Configy things. (further discussion on this below) Macro naming and general Boostification clean-up. -------- Reviews -------- There was a good amount of discussion about the library on both the dev and user mail lists. I want to personally thank those who got involved in the review. You make the process work! Result summary: Accept: 7 Reject: 1 No-decision: 3 The no-decision reviews provided valuable input and discussion threads. While it would be my preference to have the review authors provide a final verdict, I was grateful for the time and energy they spent with the library and formulating thoughts into emails for discussion. Some comments from reviews: “I find function preload() really great and novel. … This really makes the error reporting code brief, clean and bug-free.” “I like LEAF very much and there's a lot offered here…” “I like it.” “...it allows bridging multiple error handling strategies and usage patterns in an efficient way.” About the docs: “They look good and manage to explain hard concepts in a very approachable fashion.” “The documentation is great -- in terms of styles it's probably the best I've seen for a C++ library.” “Clear, friendly and complete.” -------------- Some Thoughts -------------- While there was overwhelming consensus that LEAF should be included into Boost, the process is not democratic. I have spent considerable time understanding the concerns raised in each of the reviews and in particular the singular rejection. Emil took time responding to each of the reviews. The exchanges were fruitful and both “conditional accept” and “reject” reviewers changed their verdicts to accept along the way. Most of the concerns were amicably resolved. I am comfortable with the design choices and implementation made by the author for the remaining items. One reviewer brought up the re-implementation of Boost.Config type facilities. This of course is a complex issue for a library with zero dependencies. The ability to simply drop the Boost.LEAF directory into a project and run is a definite plus for a specific user segment. Being able to modify a single Boost.Config repository to support WackyCompiler14 targeting LEG Core and get a bunch of libraries for the ride is also a plus. Emil and I have discussed these concerns and the best choice seems to be defaulting to zero dependencies and the option to pull in Boost.Config to provide configuration type facilities if needed. Accepting a library into Boost is as much about the library as it is bringing the author into a group. While Emil is already part of the author crowd, it was clear to me through his careful, informative, and patient responses that the addition of Boost.LEAF brings professional maturity that strengthens the community. A user with more than a year of experience with the library voted acceptance based on the “qualities of the library itself and the responsiveness and openness for feedback of its author.” Throughout the review period, Emil integrated feedback to both the documentation and code in another branch. It was wonderful to see the community provide input and the author respond so quickly to produce a better final result. Thank you Emil for your vision of better error handling and striving to bring us along! -- Michael Caisse Ciere Consulting ciere.com

3 2

[log] logfile not created where expected
by Barend Gehrels 08 Sep '20

08 Sep '20

hi, I encountered a bug, most probably, in Boost.Log It is reproduceable in the tutorial_logging.cpp : https://www.boost.org/doc/libs/1_74_0/libs/log/example/doc/tutorial_logging… The short code should create a file named "sample.log". But it does not, instead it creates a file called "00000.log", with the expected lines logged in that file. If I compile and run exactly the same tutorial in Boost 1.70, the file sample.log is indeed created with the same content. The problem is already there in Boost 1.73 What is the problem? Is there a workaround for it? Thanks, regards, Barend

3 2

Re: [boost] Review Manager needed for Boost.Lambda2
by Mateusz Loskot 08 Sep '20

08 Sep '20

Bjorn, thank you for reminding me about it. I've been offline for several weeks and I might have missed it happened already (lots of communication moved to Slack too). Mateusz Loskot, mateusz(a)loskot.net (Sent from mobile, may suffer from top-posting) On Tue, 8 Sep 2020, 20:39 Bjorn Reese, <breese(a)stofanet.dk> wrote: > On 2020-09-08 19:39, Mateusz Loskot via Boost wrote: > > On Tue, 8 Sep 2020 at 17:02, Peter Dimov via Boost > > <boost(a)lists.boost.org> wrote: > >> > >> I turned this into a mini-library, https://github.com/pdimov/lambda2, > and > >> I'd like to submit that to Boost. > >> > >> I'm looking for a review manager. > > > > FYI, added to the schedule. > > Strictly speaking, he needs an endorsement first. >

2 1

buffer_size behavior in boost::iostreams::filtering_istream
by Justin McManus 07 Sep '20

07 Sep '20

I have some code that works as intended, but it requires setting a buffer_size parameter to zero on a std::ifstream pushed onto a filtering chain, and I'd like to understand why, to ensure I'm not introducing a bug or a hack. I have essentially the following code: -------------------------------------------------------------------------------------------------------- std::ifstream m_jf("json_filename", std::ios_base::in | std::ios_base::binary); std::locale utf8_locale("en_US.UTF-8"); m_jf.imbue(utf8_locale); boost::iostreams::filtering_istream m_inbuf; m_inbuf.push(boost::iostreams::bzip2_decompressor()); m_inbuf.push(m_jf); std::string m_line; while (std::getline(m_inbuf, m_line)) { // Process the current line from the JSON file } -------------------------------------------------------------------------------------------------------- What I find is that the std::getline call will fail before the code has reached the EOF. It will always fail at the same line in a given JSON file, but it will fail on different lines in different JSON files. It's perfectly reproducible. However, if I change lines 4 and 5 to m_inbuf.push(boost::iostreams::bzip2_decompressor(), *0*); m_inbuf.push(m_jf, *0*); then the problem goes away. My question is, Why does setting the buffer_size parameter to zero solve the issue? What does this do, exactly? I saw the suggestion to set the buffer size this way from an old post in 2009, and it appears to work, but I'd like a deeper understanding of what's happening under the hood. If the buffer size is set to zero, what does the underlying implementation do, and how might this influence whether std::getline fails before the EOF? Thanks very much, Justin -- Justin McManus, Ph.D. Principal Scientist Lead Computational Biologist and Statistical Geneticist Kallyope, Inc. 430 East 29th Street, Suite 1050 New York, NY 10016

3 4

type detection macros + multiprecision + io
by Gero Peterhoff 07 Sep '20

07 Sep '20

Hello Developer, I noticed that some type detection macros and boost::float128_type or numeric_limits do not work reliably: - BOOST_HAS_FLOAT128 with clang and icc do not work, gcc is ok - BOOST_HAS_CHAR32/16_T, BOOST_NO_CHAR32/16_T are not defined, but either BOOST_HAS_TYPE or BOOST_NO_TYPE should be defined; see later - with clang there is no boost::float128_type and an error when including boost/multiprecision/float128.hpp (quadmath.h) - with clang and icc the numeric_limits<float128_t> are not available (gcc ok) see https://godbolt.org/z/95PfTG In general it would make sense: - convert the detection macros to a uniform naming scheme: always BOOST_HAS_TYPE_T (with _T at the end) or BOOST_HAS_TYPE (without _T), but not mixed/both - in multiprecision and math: 1) float: renaming typenames to eg floatBits_mbt (m: multiprecision, b: binary); floatBits_mdt (d: decimal) 2) integer: renaming typenames to e.g. u/intBits_mt; u/intBits_mct (c: checked) 3) based on this, renaming boost::float/int128_type to boost::float/int128_t so that it is always clear and there is no confusion. You can do that for all types, e.g. some DSP/microcontrollers do not support u/int8/64_t etc. I did that quickly for gcc (has_type.hpp) - of course that has to be in the corresponding boost/config/compiler/* and platform/* headers are implemented. Building on this, feature test macros can then be made available (features.hpp). Can you please implement the io-operators and string-conversions for u/int128 (in e.g. boost/math/cstdint/cstdint_iostream.hpp)? thx and regards Gero

5 4

[sync] Documentation ?
by Edward Diener 06 Sep '20

06 Sep '20

There is a 'sync' library in the Boost build tree as a submodule, but I see no documentation for it in Boost 1.74 itself. Is this currently a Boost library, or what is it ?

2 1

Cryptography for Boost. Boost.Crypto3.
by Mikhail Komarov 04 Sep '20

04 Sep '20

Hello! Some time ago I promised to show something about cryptography library architecture and implementation for Boost (https://lists.boost.org/Archives/boost//2020/02/248205.php <https://lists.boost.org/Archives/boost//2020/02/248205.php>), so here I am. I’m actually glad my two innocent letters triggered such a conversation. That is what I wanted to see! Please, read this letter very carefully, because some explaining needs to be done before you go to the code. By the way. The code: https://github.com/NilFoundation/boost-crypto3 <https://github.com/NilFoundation/boost-crypto3>. Warning. This letter contains mentioning of my non-commercial organizations I develop Boost.Crypto3 with. Don’t consider that as advertising. It is not supposed to be an advertisement. So, what cryptography for Boost (and probably STL some time after) should look like? 1. It should definitely be simple to use and implemented with some generic programming spirit. That is exactly what was done. Remember std::transform? Typical usage technique for all of the modules of a suite looks as follows. Classic iterator pair with output iterator: using namespace boost::crypto3; std::string input = “Weird German 2 byte thing: Ã.“, out; encode<codec::base64>(input.begin(), input.end(), std::inserter(out, out.end())); Classic iterator pair with output value return: using namespace boost::crypto3; std::string input = “00112233445566778899aabbccddeeff”; std::string key = “000102030405060708090a0b0c0d0e0f”; std::string out = encrypt<block::rijndael<128, 128>>(input.begin(), input.end(), key.begin(), key.end()); C++20 Ranges (or Boost.Range) usage: using namespace boost::crypto3; std::vector<std::uint8_t> input = {0x27, 0x0f, 0xb1, 0x89, 0x82, 0x80, 0x0d, 0xa6, 0x40}; std::string out = encode<codec::base32>(input); // or encode<codec::base32>(input, out); What about generic encoding/encryption/signing/hashing/%name_your_action% interface for classes? You can definitely do that in case you define implicit conversion of your class to integral type. I’m thinking of introducing Inspectable concept which will require for the developer to have a function in his class which would return every class member which developer thinks needs to be encrypted/hashes/encoded/etc, converted to the particular algorithm’s format. (e.g. satisfying Integral concept for ciphers/codes/hashes). 2. It should contain only time-proven schemes implemented with well-known and proven techniques. Yes. Boost.Crypto3 (https://github.com/NilFoundation/boost-crypto3 <https://github.com/NilFoundation/boost-crypto3>) is derived from =nil; Crypto3 C++ Cryptography Suite (https://github.com/NilFoundation/crypto3 <https://github.com/NilFoundation/crypto3>), which my non-commercial foundation designed and developed for it’s projects. A little bit of information on how exactly it was derived from the original suite you can get from the readme.md in both or repositories. As far as you can see in the original repository, the suite contains some very novel schemes (e.g. Verifiable Delay Functions: https://github.com/nilfoundaton/crypto3-vdf.git <https://github.com/nilfoundaton/crypto3-vdf.git>) and it is going to contain more (threshold cryptography, zero-knowlege cryptography, cryptographic accumulators etc.). But Boost-ified version has to be a solid one. No novel schemes. Only proven ones with proven implementation techniques. Which ones? This is what Boost community is up to decide. So, the question for the community. What schemes should be included? For now we only present small set of block ciphers, hashes and codecs listed in here https://crypto3.nil.foundation/projects/crypto3/db/d97/group__codec.html <https://crypto3.nil.foundation/projects/crypto3/db/d97/group__codec.html>, https://crypto3.nil.foundation/projects/crypto3/db/d97/group__hashes.html <https://crypto3.nil.foundation/projects/crypto3/db/d97/group__hashes.html>, https://crypto3.nil.foundation/projects/crypto3/d2/dba/group__block.html <https://crypto3.nil.foundation/projects/crypto3/d2/dba/group__block.html>. (Or you can find the list in the include directories of particular repositories: https://github.com/nilfoundation/crypto3-block.git <https://github.com/nilfoundation/crypto3-block.git>, https://github.com/nilfoundation/crypto3-codec <https://github.com/nilfoundation/crypto3-codec.git>.git <https://github.com/nilfoundation/crypto3-codec.git>, https://github.com/nilfoundation/crypto3-hash <https://github.com/nilfoundation/crypto3-hash.git>.git <https://github.com/nilfoundation/crypto3-hash.git>). Peter (Dimov), I’m aware of your abandoned hash library implementation (https://github.com/pdimov/hash2 <https://github.com/pdimov/hash2>) based on Vinnie’s paper. I would really like to see it’s contents and concepts (probably) adapted to hash module of Boost.Crypto3. Would be a great synergy. 3. It should have a concept-based architecture. Concept-based architecture supposes every reused type trait to be formalized, and standardized. This is what exactly has been done. In particular, concepts for contents of Boost.Crypto3 are listed in sufficient documentation chapters: https://crypto3.nil.foundation/projects/crypto3/df/d5d/block_ciphers_concep… <https://crypto3.nil.foundation/projects/crypto3/df/d5d/block_ciphers_concep…>, https://crypto3.nil.foundation/projects/crypto3/d7/da8/codec_concepts.html <https://crypto3.nil.foundation/projects/crypto3/d7/da8/codec_concepts.html>, https://crypto3.nil.foundation/projects/crypto3/d1/d1f/hashes_concepts.html <https://crypto3.nil.foundation/projects/crypto3/d1/d1f/hashes_concepts.html>. Long story short. We standardize stateless policies containing all the params as constexpr ones used for functions (interface-functions like encrypt/decrypt) and actual algorithms. We also figured out that most of cryptographic algorithms are about accumulation and only then processing. So we used Accumulator concept from Boost.Accumulator to accumulate (surprise surprise) data in a format, which is required by particular algorithm to be passed into. You can get the idea of how I’ve merged the Accumulator concept in from architecture and implementation notes (for Block Ciphers) in here: https://crypto3.nil.foundation/projects/crypto3/db/dee/block_ciphers_impl.h… <https://crypto3.nil.foundation/projects/crypto3/db/dee/block_ciphers_impl.h…>. Pretty drafty as well, but better than nothing. Yes, Hash concept should be made consent with currently existing Hash concept. This is in progress. Vinnie (Falco), I remember, you’ve mentioned some more generic concepts like OneWayFunction (in here: https://lists.boost.org/Archives/boost//2020/02/248228.php <https://lists.boost.org/Archives/boost//2020/02/248228.php>). I agree, we should do that, but we simply had no time to put this fine idea to our architecture. We would really appreciate any help with that. Cristopher (Kormanyos), I’m aware of your CRC catalog library (https://github.com/ckormanyos/crc-catalog <https://github.com/ckormanyos/crc-catalog>) I like it because of how in particular it is implemented. I would really like to merge it into our CRC implementation in Crypto3.Hash. By the way. I wonder if we could sometime remove separate Boost.CRC library and use CRC from more generic Boost.Crypto3? Hypothetically. Just asking. Yeah, we have checksums being implemented in Crypto3.Hash (and in Boost.Crypto3 as well), but they were simply not verified yet, so they are hanging in a PR (https://github.com/NilFoundation/crypto3-hash/pull/68 <https://github.com/NilFoundation/crypto3-hash/pull/68>). 4. Other modules? Roadmap? Yes, there will be other modules being proposed in some time. Public Key cryptography in Boost? Yes. Based on enhanced for cryptographic purposes Boost.Multiprecision (https://github.com/NilFoundation/crypto3-multiprecision <https://github.com/NilFoundation/crypto3-multiprecision>). SSL based on Boost.Crypto3? Yes. Why not. We are already in progress. Major updates are going to be performed with merging in the Boost-ified version of bunch of cross-dependent modules of the original suite. For example, public key cryptography would require enhancing Boost.Multiprecision (which is already in progress) and introducing finite fields library (https://github.com/NilFoundation/crypto3-algebra <https://github.com/NilFoundation/crypto3-algebra>). By the way. The original =nil; Crypto3 suite is highly modular. Every cryptography field is emplaced in separate submodule. There are more than 30 of them now in total (counting closed ones)(yeah, it is huge). Would you like to keep this modularity (like introducing Boost.BlockCiphers, Boost.Hashes and Boost.Codec instead of Boost.Crypto3)? Or do we need to keep everything in header-only Boost.Crypto3? I would vote for the second option. John (Maddock), do you understand now why I was attempting to get accepted those strange PRs in Boost.Multiprecision for the last year? Degski (Sorry, I’m not aware of your name), I remember you’ve mentioned some kind of compression library of yours. I would like to see the compression in the suite. Do you think I could fork it and fit into our architecture? 5. Why do we think we can implement properly design and cryptography? Ask me :). 6. Conclusion. In some time, this would definitely result in C++ Standardization Committee proposal. It is a long way, but I hope to bring it there. What we would like to hear from Boost community is some guidance about what in particular from this field would be useful for Boost, proposals and suggestions about architecture and concepts. Let us standardize some cryptography together (starting with this). Sincerely yours, Mikhail Komarov nemo(a)nil.foundation

6 8

Re: [boost] ASIO SSL Memory Leaks
by abrarov＠mail.ru 01 Sep '20

01 Sep '20

Hi John, Welcome to this mailing list! Doesn't Asio call SSL_shutdown here: https://github.com/chriskohlhoff/asio/blob/master/asio/include/asio/ssl/deta il/impl/engine.ipp#L325 ? Regarding memory leaks - cold you please provide a minimal example reproducing memory leak including the way you detect memory leak? Could chriskohlhoff/asio GitHub issue #368 (https://github.com/chriskohlhoff/asio/issues/368) be your case? Regards, Marat Abrarov.

1 0

ASIO SSL Memory Leaks
by John A 01 Sep '20

01 Sep '20

Hello y'all, This is my first post to this listserv though I've been on others for ~30 years. I have a Boost question, ob duh. Using the SSL_shutdown() outlined here: https://www.openssl.org/docs/man1.0.2/man3/SSL_shutdown.html from within Boost, there isn't an object to associate with this shutdown call. Secondly, we have memory leaks (~10k bytes) using the SSL library via Boost socket calls using the ASIO SSL streams. What am I missing? What advisement can be offered? Ideally, we want to call SSL_shutdown() from within Boost, though I am missing something. Best regards, John Aronetics.com We Speak ITR +1-216/307-5760

3 3

ASIO: Same code for tcp, unix domain sockets (websockets via beast)
by Matthias Loy 26 Aug '20

26 Aug '20

Hello, we are implementing a service that is to be available via tcp, unix domain sockets (and websocket). Websocket might be out of scope since it is not part of asio. All those protocols are streaming protocols and should behave in the same way: read some bytes, write some bytes. I would like to have the code implemented only once to handle several protocols. Not having one for local::stream_protocol::socket and another one for ip::tcp::socket. Until now I was not able to find something like base classes that allow me to do that. I only found code that works for tcp or unix domain sockets (local). The protocol is not to be decided at compile time but on runtime. Hence I'm having problems using templates here. The documentation of async_read states that the stream has to support the AsyncReadStream concept. Is there a way to get something supporting this concept from local::stream_protocol::socket and ip::tcp::socket? Best regards, Matthias

4 3

JSON library scheduled for review
by Mateusz Loskot 25 Aug '20

25 Aug '20

Hi, A brief announcement from the review wizards: Formal review of the JSON library has been scheduled to take place between October 9 and October 18, 2020. Details and links available here https://www.boost.org/community/review_schedule.html We'd like to thank Pranam Lashkari (Boost.GIL, [Boost.]Astronomy, Boost GSoC) for volunteering to act as the review manager. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

Shallow Hal Needs A Gal!
by Vinnie Falco 25 Aug '20

25 Aug '20

And Boost.JSON needs a review manager! -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

3 4

Modules
by Damian Vicino 24 Aug '20

24 Aug '20

Hi, Are there any guidelines on the use of modules inside boost? Are we planning any steps for adoption of them?

9 18

You Won't Believe This!
by Vinnie Falco 23 Aug '20

23 Aug '20

But Boost.JSON needs a Review Manager! Don't be shy now! Repository: https://github.com/cppalliance/json Documentation: http://vinniefalco.github.io/doc/json/index.html -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

7 10

[release] Boost 1.74.0 Release Candidate 1
by Marshall Clow 21 Aug '20

21 Aug '20

The first release candidates for the 1.74.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.74.0/source/> The SHA256 checksums are as follows: 9ea3fc8573413f4d4b2c4d448110b6cb0467df834304112e143c7edb09ae71e9 boost_1_74_0_rc1.7z 8b6c429a41f7cac1880594adf8d1d6f0cc1cf19f8980c6b86ac38ef8b3d8a4e0 boost_1_74_0_rc1.tar.bz2 a0a96a9bb3863863e034cafc825b2ddba4249c7d278b76df1277295e7c7afbf2 boost_1_74_0_rc1.tar.gz d4f31cce9d5fbd55691dc2f5fb73380e95aa66426c891ceb3ebdfc6616022842 boost_1_74_0_rc1.zip 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

6 10

[Core] gdb/VS Pretty-printers for Boost
by Jeff Trull 21 Aug '20

21 Aug '20

There's been a number of independent efforts to produce pretty-printers (or "visualizers") for different popular Boost libraries. The one I like most due to its thoughtful execution is probably this one <https://github.com/ruediger/Boost-Pretty-Printer>. But maintaining a set of pretty-printers out of tree is a challenge for all the usual reasons. Having libraries optionally supply and maintain them is much more sustainable. Would it be possible to define a small set of standard ways (file locations, build steps) for a library to store and install pretty-printers for gdb and/or Visual Studio? Thanks, Jeff

7 10

achriving multiple files under a folder
by ravi shankar 20 Aug '20

20 Aug '20

Hi All, Is there a possibility to archive multiple files present under a directory into a single archive file using boost libs. folder structure: folder1 / \ folder2 file2 / file1 Please help me in this regard.

1 0

PFR (Precise and Flat Reflection) by Antony Polukhin scheduled for review
by Mateusz Loskot 18 Aug '20

18 Aug '20

Hi, A brief announcement from the review wizards: Formal review of Antony's library has been scheduled to take place between September 28 and October 7, 2020. Details and links available here https://www.boost.org/community/review_schedule.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[container] devector merged into Boost.Container
by Ion Gaztañaga 17 Aug '20

17 Aug '20

Hi to all, Many years after the review (it was finished in 2017), I managed to find some time to make the review result possible and integrate double-ended library's "devector" class in Boost.Container. I merged the implementation some days ago in develop branch and I hope we can merge it to master soon. Several changes were needed (C++03 support, similar interface/features to other containers, removed some non-essential operations that were not present in other containers...) to do a proper integration. It's might not be production-ready, documentation might be still lacking, but I think it's a good starting point. Initial performance benchmarks seems to show I haven't broken anything important;-) I made no changes to original devector's main design, no experiments with growth or data movement policies. There were many good ideas in the review and outside boost we have experiments worth trying. Examples: - https://lists.boost.org/Archives/boost/2017/10/239316.php - http://larshagencpp.github.io/blog/2016/05/22/devector I also plan to slowly start sharing more implementation details between devector and vector to avoid code duplication and ease maintenance, and adding some missing operations in devector that are in vector (like default initialization insertions). Many thanks to Benedek for his patience, and great design/implementation (including a detailed test-suite, absolutely essential to ease the work I needed to do to integrate devector in the library). Better late than never ;-) Best, Ion

5 6

Embarcadero C++ clang-based PRs
by Edward Diener 15 Aug '20

15 Aug '20

There are still 9 Boost libraries which have not accepted my individual PR for the library which would enable the Embarcadero C++ clang-based compilers ( bcc32c, bcc32x, bcc64 ) to work with those libraries. These libraries are: circular_buffer - https://github.com/boostorg/circular_buffer/pull/34 graph = https://github.com/boostorg/graph/pull/215 iostreams = https://github.com/boostorg/iostreams/pull/112 parameter = https://github.com/boostorg/parameter/pull/103 program_options = https://github.com/boostorg/program_options/pull/94 thread = https://github.com/boostorg/thread/pull/317 typeof = https://github.com/boostorg/typeof/pull/18 units = https://github.com/boostorg/units/pull/47 unordered = https://github.com/boostorg/unordered/pull/16 1) None of these PRs affect any compilers but the Embarcadero C++ clang-based compilers. I can guarantee that. 2) None of these PRs change the logic of any of the libraries in any way. 3) All the PRs will allow the Embarcadero C++ clang-based compilers to not be subject to workarounds in these libraries for the old Borland/Codegear/bcc32 compiler, to which the Embarcadero C++ clang-based compilers are not related in any way. 4) All the PRs have passed all the CI tests which had not already been previously broken by the CI setup for the library itself. You can see my comments about any of the failing CI tests and why they have absolutely nothing to do with the PR for the library. If some maintainer who has write access to any of these libraries could merge any of these PRs it would most appreciated by me. Thank you !

2 1

[release] Boost 1.74.0
by Marshall Clow 14 Aug '20

14 Aug '20

Release 1.74.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 contains 1 new library and numerous enhancements and bug fixes for existing libraries. For details, including download links, see < http://www.boost.org/users/news/version_1.74.0> You can also download directly from: < https://dl.bintray.com/boostorg/release/1.74.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. Thanks, -- The Boost Release Team Marshall Clow, Michael Caisse, Glen Fernandes

2 1

[release] 1.75.0 open for merging
by Marshall Clow 14 Aug '20

14 Aug '20

The master branch is open for merging all stable changes from develop, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging does not require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html [ Note: this will be updated later today ] Release schedule explanation: https://github.com/boostorg/wiki/wiki/Releases%3A-Schedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Boost Release Team

1 0

[test] runtime failures with "main() should return report_errors()"
by stefan 14 Aug '20

14 Aug '20

Hello, With the Boost.Python tests I'm observing a couple of mysterious failures, where the test application fails *after* the actual test succeeded, with a message main() should return report_errors() I gather this error is emitted by the Boost.Lightweight_test library whenever a test's main() function does not call `report_errors()` at the end. The problem in my case is that my failing tests are not (explicitly) using Boost.Lightweight_test. In fact, in all of the failing cases I'm not even writing a `main()` function, as the test driver is a Python script that's importing a (test) module. For example: https://www.boost.org/development/tests/master/developer/output/teeks99-05-… Does anyone understand or has an idea how this could happen, and how to fix this ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

2 2

current situation with clang-cl?
by Dennis Luehring 13 Aug '20

13 Aug '20

some of my project using boost building with clang-cl but there are still some libraries that don't is there any official interest in supporting clang-cl or is it up to a library maintainer to support it? many project of mine building better and better, boost 1.73 currently is neary full useable with clang-cl without any problems today i tried to compile a 600KLOC project and it failed with the same problem Libreoffice got they are using a patch to "fix" its used boost version https://github.com/LibreOffice/core/blob/62808ef28e05eee4945a6a15d981350d13… https://github.com/boostorg/thread/issues/286 "clang-cl defines _MSC_VER by ms-compatibility but BOOST_MSVC will not be set." still a problem? there are some Issues reported but i don't know if fixes are wanted of if there is a strategy to support clang-cl out of the box

4 13

Re: [boost] using clang-cl with 1.74-rc2 forces auto-link to search for clangw10 libs instead of using existing Microsoft-cl built libs
by pbristow＠hetp.u-net.com 12 Aug '20

12 Aug '20

> -----Original Message----- > From: Boost <boost-bounces(a)lists.boost.org> On Behalf Of Dennis Luehring via Boost > Sent: 12 August 2020 14:59 > To: boost(a)lists.boost.org > Cc: Dennis Luehring <dl.soluz(a)gmx.net> > Subject: [boost] using clang-cl with 1.74-rc2 forces auto-link to search for clangw10 libs instead of using > existing microsoft-cl built libs > > using latest VS2010 and llvm/clang 10.0.0 release (10.0.1 is a litte bit more recent but no windows builds > available) Aside: WinLibs standalone build of GCC and MinGW-w64 for Windows at Winlibs.com has very recent builds, mainly intended for Mingw-64, but often OK for Windows clang-cl too? (I am using Clang and GCC from this site with CodeBlocks IDE and also using b2/bjam but I could not get the clang-win .exe to build reliably and am using clang-linux .exe in my user-config.jam. However this isn't any help to your difficulties ☹ ). > compiler set to 2017 microsoft-cl in VS2017: > libboost_serialization-vc141-mt-gd-x32-1_74.lib > > compiler set to clang-cl in VS2017: > libboost_serialization-clangw10-mt-gd-x32-1_74.lib > > that behavior is new to 1.74 - older boosts versions 1.69..1.73 would use the vc141 libs what makes > sense because clang-cl is the microsoft-cl compatible replacement > > normaly there is no need to switch any external libs when using clang-cl instead of microsoft-cl

1 0

using clang-cl with 1.74-rc2 forces auto-link to search for clangw10 libs instead of using existing microsoft-cl built libs
by Dennis Luehring 12 Aug '20

12 Aug '20

using latest VS2010 and llvm/clang 10.0.0 release (10.0.1 is a litte bit more recent but no windows builds available) compiler set to 2017 microsoft-cl in VS2017: libboost_serialization-vc141-mt-gd-x32-1_74.lib compiler set to clang-cl in VS2017: libboost_serialization-clangw10-mt-gd-x32-1_74.lib that behavior is new to 1.74 - older boosts versions 1.69..1.73 would use the vc141 libs what makes sense because clang-cl is the microsoft-cl compatible replacement normaly there is no need to switch any external libs when using clang-cl instead of microsoft-cl

1 0

[release] Boost 1.74.0 Release Candidate 2
by Marshall Clow 12 Aug '20

12 Aug '20

The second release candidates for the 1.74.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.74.0/source/> The SHA256 checksums are as follows: 903fd40074de8dc733d2f0b6b0642e43b714653eaeb79289b12161b9567fae97 boost_1_74_0_rc2.7z 83bfc1507731a0906e387fc28b7ef5417d591429e51e788417fe9ff025e116b1 boost_1_74_0_rc2.tar.bz2 afff36d392885120bcac079148c177d1f6f7730ec3d47233aa51b0afa4db94a5 boost_1_74_0_rc2.tar.gz a0e7ce67c52d816708fdeccdd8c9725626ba61254c13c18770498cacd514710a boost_1_74_0_rc2.zip Changes from RC1: * Fix a recently introduced bug in Boost.Asio where it would read from uninitialized memory. 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

3 3

[release] Boost 1.74.0 beta 1 released
by Marshall Clow 09 Aug '20

09 Aug '20

Boost release 1.74.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.74.0.beta.1/source/> The SHA256 checksums are as follows: 577a6b575ff2c227e14cce1b929c73d969475e58f3d2ab2901ad234f773bbd12 boost_1_74_0_b1.7z ba09c72dc848e7c0904922967014d853897b5a634926c910cc3b1fd627c31605 boost_1_74_0_b1.tar.bz2 2ccdc39efa076822cf1b359f9449f9d07707f3e27a18b393297b25885a9ff45b boost_1_74_0_b1.tar.gz c267c450166e040a374eaddab5e583cef09f6c3fe96a4db826172d0315c38dd5 boost_1_74_0_b1.zip For details of what's in the release, see < https://www.boost.org/users/history/version_1_74_0.html>. Please download the beta, give it a try, and report any problems you encounter. Issues that were found during the beta release process and will be fixed for the final 1.74.0 release: * The Boost.STLInterfaces documentation was left out of the beta. * Some of the Boost.Geometry documentation files have very long names; this could cause problems on platforms (like Windows) with shorter limits on path lengths. * There is a compile error in Boost.ASIO when compiling with 32-bit MSVC-14.2 with BOOST_BEAST_NO_TS_EXECUTORS. Thanks, -- The Boost Release Team

2 3

[release] Master branch now closed for 1.74.0 release
by Marshall Clow 06 Aug '20

06 Aug '20

1 0

Re: [boost] Hello everybody, I have something to share about the shared_ptr class
by 逸霖杨 04 Aug '20

04 Aug '20

Last post was sent directly to Rob, I forgot to cc list.bost.org. Thinking of the multiple calling of the detors, which is suggested by Rob and other members, I came up with some ideas. This IS about specification. If class A has a dispose method like class A { A(){} ~A(){} //Dispose method: !A(){} }; Where !A() can be called multiple times and ~A() can be called only one time. Everything rcgc_ptr delegates will be called its dispose in !A() and therefore multiple times to just decrease the reference count and finally call ~A() when real delete happens. And this can be done on the compiler level (!A() maybe not visible at all or just visible when you use like ~A()). Saying this algorithm is a part of the C++ language itself, then C++ has no need to manually manage pointers (at least the unwanted management). Idea is inspired by all of you especially Andrey Janson and Rob. Thank you all! Best Regards, Yilin

3 10

[release] 1.74.0 post-beta merges
by Marshall Clow 03 Aug '20

03 Aug '20

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See <https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy> Reminder: The master branch closes for the release on August 5th. -- The release managers

13 52

Hello everybody, I have something to share about the shared_ptr class
by 逸霖杨 02 Aug '20

02 Aug '20

Hello dear boost members, I’m quite honored to join this mail list for the first time! As I was told that the boost project is where the shared_ptr class originated, so I think it should be OK to talk about it here. Here I have some ideas and code on my version of shared_ptr class. The aim is to remove the usage of weak_ptr and fix the circular reference problem. Please check code on https://github.com/yyl-20020115/RCGC That’s the idea and primitive implementation. I don’t know exactly how to test it more widely among situations, please help me to find the very situations that this solution would fail, and I’ll try to fix it ASAP. READM.md is a good start and README_ZHCN.md is better if you can read Chinese. However, I don’t think I can illustrate the algorithm very well both in English and Chinese. Well the code speaks for itself, and please read the code and run the program. Please generate a makefile and build with CMakeLists.txt on *nix platforms if Visual Studio 2019 (where I code the project) is not available. All ideas and discussions and help from you are all very welcome! Best Regards, Yilin

6 18

[Release] Reminder: master branch closes 5-August for 1.74.0 release
by Marshall Clow 02 Aug '20

02 Aug '20

The calendar of events is up at: https://www.boost.org/development/ <https://www.boost.org/development/> — Marshall

1 0

[release] Reminder about release notes
by Marshall Clow 02 Aug '20

02 Aug '20

Please submit pull requests against https://github.com/boostorg/website/blob/master/feed/history/boost_1_74_0.q… to be included in the release notes for 1.74.0 — Marshall

1 0

Re: [boost] About rcgc_shared_ptr
by 逸霖杨 31 Jul '20

31 Jul '20

A downgrade implementation can be like this (which is actually my former implementation during the experiments) We define an interface: struct IDIsposable { virtual void Dispose() = 0; }; And implement this interface with class A class A : public IDisposable { Public; A():disposed(false){} public: virtual void Dispose(){ if(!this->disposed){ this->_pb.Dispose();//this Dispose belongs to rcgc_shared_ptr this->_pc.Dispose(); //this Dispose belongs to rcgc_shared_ptr this->disposed = true; } } bool disposed; rcgc_shared_ptr<B> _pb; rcgc_shared_ptr<C> _pc; }; And we don’t care about ~A() and let the rcgc_shared_ptr call Dispose method of the IDisposable. This would avoid the dtors definition. However, this is not as elegant as the previous given solution in C++, having to write more code which we don’t like to do, although no difference in other languages or platforms. I’m sorry that I have to call it a day now and have to get some sleep (4:06am here) Waiting for your kindly response and suggestions. Best Regards, Yilin

1 0

Re: [boost] About rcgc_shared_ptr
by 逸霖杨 31 Jul '20

31 Jul '20

Hi, I finally understand what is Top-Post. And feel very sorry for the Top-Posted emails, please pardon me. My email writer is the default one with Win10, and it replies with Chinese RE, not English, and embedding Chinese characters. Also sorry for the inconvenience when you’re reading the replies. My aim is not to replace shared_ptr or weak_ptr, I’m trying to provide another choice. Personally, I don’t like to decide when to use shared_ptr or weak_ptr and also don’t like the IUnknown way of manually memory or object allocation management, just personally. I like GC when I code in C# or Java for I don’t have to remember the trivial things beyond my design, BUT not its performance. I code this in C++ because it would be too complicated if I insert code into JavaVM or C#’s native support platform. As we have great flexibility coding whatever we want in C++ on the infrastructure level. So this is what I’m going to do with this rcgc_shared_ptr: 1. use it in my projects, and make it go through tests to see If its capable of doing things.2. Trying to make this a part of a GC based language or platform to see any performance increasing. And if possible, just as I did in emails, contribute to communities and let other coders to decide if the work Is helpful or even harmful. Please forgive me to be such a rude guy for the first time to talk so much. However, I do hope you can debug the code and hope this can be any help. Best Regards, Yilin

1 0

Still about rcgc_shared_ptr, to Andrey
by 逸霖杨 31 Jul '20

31 Jul '20

Hi Andrey, I just put Case 1 into main function and updated the GitHub project, please pull and run. I don’t have reset function for rcgc_shared_ptr, so case 2 can not work for now. Best Regards, Yilin

1 0

[gil] Can I merge one fix for regression in 1.74?
by Mateusz Loskot 27 Jul '20

27 Jul '20

Dear Release Manager, We've received bug report about regression and have just fixed it in the develop branch of GIL: https://github.com/boostorg/gil/commit/8555ba08cd53c2ec5d65ea60bae9578ad586… Can I merge this fix to master? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

[gil] Can I merge two minor fixes to header dependencies and tests for 1.7.4?
by Mateusz Loskot 26 Jul '20

26 Jul '20

Dear Release Manager, I'd like to request permission to merge these two minor fixes into GIL's master for release with 1.74 1. Fix dynamic_image extension header dependencies https://github.com/boostorg/gil/pull/508 This basically removes all-in-one #include <boost/gil.hpp from GIL's own headers. 2. Re-enable self containing header tests in CMake https://github.com/boostorg/gil/pull/509 Minor correction to an incidental disabling of headers tests in CMake. May I? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 4

Two Graphs Common Spanning Trees Issue [GSoC]
by Prakash Tiwari 24 Jul '20

24 Jul '20

Hello, Community Members and developers, I'm student of Google Summer Of Code and contributing to the pgRouting <https://github.com/pgRouting/pgrouting/>[1]. I need to use boost algorithm boost::two_graphs_common_spanning_trees. I have gone through the documentation and try to use it (with help of example.cpp) But I found that this algorithm is not returning the expected results. I have mentioned the example that I have used and explained the expected and given results <https://github.com/prakashupes/ProposalCodes/issues/1>.[2] So, please try to figure out that is it a bug implemented algorithm or It might be possible that I'm using the algorithm in the wrong way. Thanks Prakash Tiwari [1].https://github.com/pgRouting/pgrouting/ [2]. https://github.com/prakashupes/ProposalCodes/issues/1

1 0

[release] Boost 1.74.0 Beta 1 Release Candidate 1
by Marshall Clow 15 Jul '20

15 Jul '20

The release candidates for the first 1.74.0 beta release are now available at: https://dl.bintray.com/boostorg/beta/1.74.0.beta.1/source/ The release notes are not yet available. The SHA256 checksums are as follows: 577a6b575ff2c227e14cce1b929c73d969475e58f3d2ab2901ad234f773bbd12 boost_1_74_0_b1_rc1.7z ba09c72dc848e7c0904922967014d853897b5a634926c910cc3b1fd627c31605 boost_1_74_0_b1_rc1.tar.bz2 2ccdc39efa076822cf1b359f9449f9d07707f3e27a18b393297b25885a9ff45b boost_1_74_0_b1_rc1.tar.gz c267c450166e040a374eaddab5e583cef09f6c3fe96a4db826172d0315c38dd5 boost_1_74_0_b1_rc1.zip 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 Boost Release Managers

4 7

[release] Master branch now closed for 1.74.0 beta release
by Marshall Clow 12 Jul '20

12 Jul '20

1 0

[Release] master branch will be closed for the 1/74/0 beta release TODAY
by Marshall Clow 11 Jul '20

11 Jul '20

Later today the master branch will be closed for all changes. See the calendar here for more dates: https://www.boost.org/development/ <https://www.boost.org/development/> The master branch will be re-opened after the beta release. Thanks, — The Boost Release Team

1 0