May 2022 - Boost - lists.preview.boost.org

Boost.Text is looking for a (mini-)review manager
by Zach Laine 07 Dec '22

07 Dec '22

I've made all the recommended changes to Boost.Text that came up in the review. Glen, the previous review manager, recommended a mini review of Boost.Text once I'd made those changes. If you'd like to manage the mini-review, please let me know. For everyone, including potential reviewers and review managers, here are the major changes: * All the specific review feedback issues have been addressed. * The string layer is now gone. * The text layer got a major re-work. It is now a set of template-based adaptors (basic_text<>, vs. a text typedef. etc.), which lets everyone get what they want. You can change the underlying storage type (including whatever allocator you prefer), select UTF-8 or UTF-16, and change the normalization form. Glen recommended I drop this layer, but the library is way less useful without this stuff, and these changes address all the concerns raised about the text layer in the review. The updated docs can be found here: https://tzlaine.github.io/text/doc/html/index.html Oh yeah, and I added concept constraints to the whole library when you build in C++20 mode. Zach

17 46

[review][JSON] Review of JSON starts today: Sept 14 - Sept 23
by Pranam Lashkari 09 Aug '22

09 Aug '22

Boost formal review of Vinnie Falco and Krystian Stasiowski's library JSON starts today and will run for 10 days ending on 23 Sept 2020. Both of these authors have already developed a couple of libraries which are accepted in Boost(boost beast and Static String) This library focuses on a common and popular use-case for JSON. It provides a container to hold parsed and serialised JSON types. It provides more flexibility and better benchmark performance than its competitors. JSON highlights the following features in the documentation: - Fast compilation - Require only C++11 - Fast streaming parser and serializer - Easy and safe API with allocator support - Constant-time key lookup for objects - Options to allow non-standard JSON - Compile without Boost, define BOOST_JSON_STANDALONE - Optional header-only, without linking to a library (a point I would like to add in highlight: it has cool Jason logo 😝) To quickly understand and get the flavour of the library take a look at "Quick Look" <http://master.json.cpp.al/json/usage/quick_look.html> You can find the source code to be reviewed here: <https://github.com/CPPAlliance/json/tree/master> You can find the latest documentation here: <http://master.json.cpp.al/> Benchmarks are also given in the document which can be found here: <http://master.json.cpp.al/json/benchmarks.html> Some people have also given the early reviews, the thread can be found here: <https://lists.boost.org/Archives/boost/2020/09/249745.php> 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). 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 here: <http://www.boost.org/community/reviews.html> Thank you for your effort in the Boost community. -- Thank you, Pranam Lashkari, https://lpranam.github.io/

21 73

[container] Contributing 'stationary_vector' to Boost
by Mehrdad Niknami 13 Jun '22

13 Jun '22

Hi all, Happy new year! New mailing list member here. I've developed an STL-style stationary_vector class that retains elements in-place when growing. Very briefly, it is effectively a piecewise-contiguous vector, with the following advantages over vector: - Appending has O(1) overhead in the *worst* case (e.g., push_back() does not move elements) - Insertion and random-access can be done in parallel, as prior iterators & references remain valid This has a variety of benefits, including better UX (no "hiccups" due to reallocations), and the ability to simplify parallel processing of streaming data. It occurred to me the larger C++ community might find this useful. I was wondering if there would be interest in incorporating it into Boost.Container, and if so, what steps I could take to make that happen? I'm of course happy to discuss the design etc. with anyone who might be interested. Summary: https://github.com/mehrdadn/libvital/blob/master/doc/vital/container/statio… Implementation: https://github.com/mehrdadn/libvital/blob/master/include/vital/container/st… Thank you, Mehrdad

7 19

Any objections to making C++14 the current baseline for Boost support and testing?
by John Maddock 10 Jun '22

10 Jun '22

Pursuant of discussion elsewhere: Does anyone have any concrete objections to Boost moving to a C++14 baseline? This would mean: * Library authors can drop and remove all support for pre-C++14 compilers after a suitable deprecation notice in place for say 3 releases. * The community maintenance team can likewise drop pre-C++14 support from community maintained / orphan libaries. * CI tests no longer need report pre-C++14 results. * From the next release onward, the boost super-project should clearly announce in our release notes, that C++11 and earlier support may no longer be available from the start of 2023. Thoughts? Thanks, John Maddock.

6 8

exception handling anti-patterns in documentation
by Andrzej Krzemienski 30 May '22

30 May '22

Hi Everyone, I wanted to share an observation. A number of Boost libraries, in documentation, when it comes to demonstrating that a given function throws an exception, has a code sample like the following: try { > lib::function(); > } > catch(lib::exception const&) { > // handle failure > } > This applies for instance to: * Boost.Lexical_cast: https://www.boost.org/doc/libs/1_79_0/doc/html/boost_lexical_cast/examples.… * Boost.Optional: https://www.boost.org/doc/libs/1_79_0/libs/optional/doc/html/boost_optional… * Boost.URL, waiting in the review queue: https://master.url.cpp.al/url/parsing/url.html What bothers me is that this is a very dangerous antipattern related to handling exceptions. If there is any benefit to be had from exceptions, it is that they separate the "positive" control flow form the "negative" (failure handling) one. Whereas in the examples like the one above it is quite the opposite: we are trying to catch the exception as soon as it is thrown. This is usually the cause of bugs and resource leaks. Such examples also lead many young programmers into thinking that exceptions are difficult or illogical. But they are not illogical: it is antipatterns like the one above that, which are working against the design of the exception handling mechanism, that confuse the programmers and enforce bad habits. One could say that the goal of the documentation is to demonstrate, in an efficient way, the interface of the library: not to teach how to program. But I would disagree. I have always considered Boost libraries to be more than that. I personally learned a lot about how to program, organize my code and organize my thinking about abstractions from reading the documentation of Boost libraries. Boost is a place to promote better programming practices. And these "catch immediately after throw and swallow" examples just do a disservice to the community. I would like to know if there are more people in this list that feel the same way. Maybe we could come up with a systematic way of demonstrating a throwing library interface, or guidelines for documentation authors. Regards, &rzej;

8 18

nullptr vs 0
by Peter Dimov 30 May '22

30 May '22

Compilers apparently are warning on the use of 0 as a null pointer constant, suggesting we use nullptr instead. But compilers don't know that we support C++03 where nullptr isn't a thing. Case in point: https://github.com/boostorg/throw_exception/pull/22 ifdef-ing every use of nullptr is unwieldy, so maybe we need BOOST_NULLPTR added to Boost.Config? That would expand to nullptr when it's supported, and 0 otherwise.

15 38

Re: [boost] Boost MySQL Review
by Ruben Perez 28 May '22

28 May '22

CC'ing the ML, as you just replied to me. On Sun, 22 May 2022 at 14:51, Seth <bugs(a)sehe.nl> wrote: > > Rubén, quick responses to your questions: > > >> TARGET_LINK_LIBRARIES(reviewtest Boost::mysql) > > > > This shouldn't be the case at all. The second line should be sufficient. > > Could you please open an issue against the repo and post your > > CMakeLists.txt, please? > > I think I understand what I did wrong/differently. I've filed the description as https://github.com/anarthal/mysql/issues/97 for potential improvement. I think there was an error in your link_libraries command, please have a look at the issue reply. I will leave the issue open to provide an example, though. > > > Implementing MySQL semantics implies the following: > > > > value("1") == value(1) // true > > value(1.0) == value(1) // true > > > > Which reminds me of the kind of patterns that have brought us > > pain in PHP and JS, and would prefer to avoid. Do you think > > "placing values in containers" is something that adds value? > > Obviously Mysql's type system is not something we want to embrace. In fact, my stance is that `mysql::value` should be for marshaling, not as a vocabulary type. As such, I do *not* think that general purpose support for "placing values in containers" adds value. > > Implementation-specific specialized containers like `mysql::row` can already handle the type appropriately. In fact I note that it does more harm than good because of the... surprising (some would say, broken) semantics. Again, for library internal use those are fine, but end-users should not get a false sense of "normalcy". > > Perhaps the library could document some utilities like `value_equal` or `value_hash` for explicit use. I'm reluctant to remove operator== and operator!=. I'd say their behavior matches the one for variants and can be useful. I see your point and I'm completely up to removing the other relational operators. > > >> > >> 3. The documentation claim "Values do not define `std::hash` yet, as > >> `boost::string_view` does not support it" is out of date. `hash_value` has > >> been added in 1.69.0 > > > > I can see a definition of hash_value, and from what I've read this makes > > it compatible with Boost containers, but the std::hash specializations are > > in a #ifdef 0 block. AFAIR std::hash doesn't use hash_value, and > > std::unordered_set<boost::string_view> fails to compile. The same > > applies for std::unordered_set<boost::mysql::value>. > > > Boost support is hash support, and it's trivial to `template <> struct std::hash<mysql::value> : boost::hash<mysql::value>` if desired. Missed that one. Thanks. Taking your comments into account, however, I'll likely won't provide it, though. > > >> 4. On that note, consider `boost::core::string_view` for better interop > >> ("lingua franca" string_view). If you're interested I just did an exhaustive > >> side-by-side comparison of features and observable behaviour` which I can > >> share. > > > > I wasn't aware of this class. Doing a quick grep in Beast, I've found it does > > use it, but it seems located in a detail/ folder > > (<boost/core/detail/string_view.hpp>). > > Could you please provide me with your comparison and any extra info I should > > be aware of? (BTW std::unordered_set<boost::core::string_view> doesn't compile > > either). > > My impact analysis consists of a suite of Very Ugly(TM) test cases that have lead to differences marked "OBSERVABLE" in the test code. It's not intended for publication, and I was lazy by using C++17 features. However, it has the "code talks" quality in that it leaves little to the imagination. So, please remember to wear goggles: https://github.com/sehe/beast/blob/core_string_view/test/beast/core/string.… > > The main area I didn't compare was constexpr-ness. Anecdotally I got the impression that core::string_view is more consistent in constexpr-ification. In fact my analysis uncovered a bug in Boost Utility https://github.com/boostorg/utility/issues/94 > > Some other differences have been addressed for an upcoming Boost release. The related tickets can be found in this cppslack thread: https://cpplang.slack.com/archives/CD7BDP8AX/p1651467929687909 I don't think any of these differences impact this library. I've raised https://github.com/anarthal/mysql/issues/98 to address it. It still freaks me out a little including a header labeled as "detail" - why is it not available as <boost/core/string_view.hpp> rather than <boost/core/detail/string_view.hpp>? It looks like if the class wasn't supposed to be used in public interfaces. > > > I'd say that the pipeline interface > > (https://github.com/anarthal/mysql/issues/76) > > may be a better interface than multi-statement for this use case. > > I think what I tried to describe is what you call the pipeline interface. So +1 > > > Note that prepared_statement's get allocated a server-side ID, which > > we expose via the prepared_statement::id() function. Something that > > could be useful for that use case is closing a statement without a > > prepared_statement object, just using its ID. > > > It may be worth adding a hint about the native_handle with the current warning about prepared_statement's destructor. > > > > > Something I noticed while implementing these erased types is that > > having prepared_statement and resultset be I/O objects makes > > the erased interface much harder. As I've mentioned in other > > review responses, I'm thinking on replacing the following signatures: > > > > prepared_statement::execute(const statement_params<ValueIterator>&) > > prepared_statement::close() > > resultset::read_one(row&) > > > > By functions in the connection: > > > > connection::execute_statement(const prepared_statement&) > > connection::close_statement(const prepared_statement&) > > connection::read_row(resultset&, row&) > > > > Where prepared_statement and resultset would be non-templated > > types. What do you think of this API? > > I can see how it simplifies things. It feel a bit C-api to me. But I have no strong opinion either way. > It's what you think is best for users in the end. Regards, Ruben.

3 2

Re: [boost] need help with building QuickBook docs
by Andrzej Krzemienski 25 May '22

25 May '22

I managed to figure out that it is this command that triggers the error: "xsltproc" -v --stringparam boost.defaults "Boost" --stringparam > boost.libraries "../../../../libs/libraries.htm" --stringparam boost.root > "../../../.." --stringparam chapter.autolabel "0" --stringparam > chunk.section.depth "8" --stringparam generate.section.toc.level "1" > --stringparam toc.max.depth "2" --stringparam toc.section.depth "2" --path > "../../bin.v2" --path "../../bin.v2/libs/optional/doc" --xinclude -o > "../../bin.v2/libs/optional/doc/optional.docbook" > "/home/andrzej/Repos/boost/tools/boostbook/xsl/docbook.xsl" > "../../bin.v2/libs/optional/doc/optional.xml" > I am using xsl files in boost/tools/boostbook/xsl from Boost repo. The contents of optional.xml are attached. It looks like QuickBook went fine. Well, this is now manageable. I got it to the point where QuickBook can detect bugs in my *.qbk files, and I can commit changes in documentation without the fear of introducing broken sources, but without the comfort of seeing the end results. I can then watch them in https://www.boost.org/doc/libs/develop/ Regards, &rzej; pon., 23 maj 2022 o 22:54 Andrzej Krzemienski <akrzemi1(a)gmail.com> napisał(a): > > > pon., 23 maj 2022 o 22:11 Andrey Semashev via Boost <boost(a)lists.boost.org> > napisał(a): > >> On 5/23/22 22:14, Andrzej Krzemienski wrote: >> > >> > >> > pon., 23 maj 2022 o 00:30 Andrey Semashev via Boost >> > > >> > > Are you using the latest built QuickBook >> > > executable? >> > >> > How can I check my version of QuickBook? >> >> quickbook --version >> >> But if you need to ask, it is probably better to just build it from >> sources. >> > > $ quickbook --version > Quickbook Version 1.7.2 (Boost 1.76) > > > >> >> > Also, make sure you don't have some stale content in bin.v2. Your >> log >> > doesn't indicate that QuickBook was run, probably because the >> BoostBook >> > document was already there. >> > >> > I now removed everything from folder bin.v2 before running `b2 doc`. I >> > still get the same result. >> > Maybe there is a way to see intermediate results, such as the generated >> > BoostBook format? >> >> The intermediate results can be found in bin.v2/libs/optional. >> > > So, the only intermediate result I found there is > bin.v2/libs/optional/doc/optional.xml (enclosed). > It has: > > <!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN" " > http://www.boost.org/tools/boostbook/dtd/boostbook.dtd"> > > Which is the output of quickbook, I suppose. > > I am using libxslt-1.1.35-1.fc36.x86_64, and it seems the lowest one that > I can get on my Fedora. > > # xsltproc --version > Using libxml 20914, libxslt 10135 and libexslt 820 > xsltproc was compiled against libxml 20912, libxslt 10135 and libexslt 820 > libxslt 10135 was compiled against libxml 20912 > libexslt 820 was compiled against libxml 20912 > > Regards, > &rzej; > > >> _______________________________________________ >> Unsubscribe & other changes: >> http://lists.boost.org/mailman/listinfo.cgi/boost >> >

2 2

Need help with SOCKS-Asio library
by Alan de Freitas 25 May '22

25 May '22

Hi! First of all, I'd like to apologize for asking for help last time during the Boost.MySql review. Terrible timing. :) So considering our recent discussions about the future of Boost, where providing more protocol implementations comes up frequently, we started this SOCKS <https://en.wikipedia.org/wiki/SOCKS> library I would like to "re-announce." The library is based on Asio and already contains the most relevant operations. There's also a client example and minimal proxy server example you can already use with your browser. At this point, I'd like to know if any kind soul, including the Asio experts, could have a quick look (as quick as you want) and provide some feedback regarding the implementation or even just the suitability of the library direction. Repo: https://github.com/alandefreitas/socks_proto Docs: https://develop.socks-proto.cpp.al/ #boost-socks on Slack Thanks! -- Alan Freitas https://github.com/alandefreitas

5 7

What do I need Boost for?
by Andrzej Krzemienski 25 May '22

25 May '22

Hi Everyone, In connection with the recent discussions on the future of Boost, I would like to offer a perspective of someone who is a consumer of open-source (but also commercial) libraries. In my work I often find myself in a situation where I need to use a new library for: * logging * unit testing * communication with DB * parsing requests XML, or simplified XML (without Unicode or less popular XML features), JSON * validating requests against XML/JSON schemas * HTTP communication * etc... I do not necessarily need Boost libraries for that. I need libraries that satisfy my criteria for correctness, safety, performance, and conformance with a certain programming style (e.g., a library cannot force me to inherit all my classes from class `Object`). These libraries do not necessarily have to come from one source. But they have to *interoperate* with one another. When I select a new library my concerns are usually the same: 1. Does the author understand the problem of exception safety and failure safety in general? The declaration "this library is exception safe" is an indication that the author at least heard about the term, but is still insufficient. I become convinced when I see a listing: these functions offer commit-or-rollback guarantee, these functions offer basic failure-safety guarantee, these functions offer other guarantees, like never-empty for some implementations of variants. 2. Does the author understand the problem of thread-safety? Similarly here, the note "this library is thread-safe" at least indicates that the author is aware of thread-safety problems. I feel more confident when I see the listing: "these functions can be called simultaneously from multiple threads", or similar declarations. 3. Does the library use the established patterns in C++, like value semantics, strong types? 4. Will the library give me the control over resource management? Or will it allocate like 30 threads behind my back, when I least expect it? 5. Will it interoperate with other libraries that I choose for other tasks? 6. Is the library actively maintained? 7. Is the library *decently* documented? (Not only the repetition of declarations from the header files.) 8. Did the author study the domain deeply, and has come up with the optimum concepts and the interface? Boost is often my first place to go. Because I have a high level of confidence that my expectations will be satisfied. But I do not always prefer Boost. For instance for unit tests I go to Google.Test, for instance, because I strongly disagree with the choice for how the precision for floating-point comparisons is silently chosen in a non uniform way. My confidence in boost stems from the review process and the assembly of experts that I trust. One could say that Boost offers a certification mechanism, even if informal. I do not care that much if all libraries come from one source, but I would love there to be a common certification body (even if informal) that would say "this library meets a certain set of criteria". I desperately needed Boost in the past because it offered a really basic fundamental primitives that were missing from the Standard library, as well from the language: optional, variant, tuple, any, shared_ptr, but also BOOST_FOREACH, BOOST_AUTO. You could call the types from the list the "vocabulary types": they can be used in other third party libraries, and therewith different libraries can interoperate seamlessly owing to these types. Today, these types from Boost do not necessarily fill this role anymore because we have the std equivalents. But Boost.ASIO can be thought of as such a building block: it can be used as a base for many higher-level libraries that interoperate owing to the same asynchrony model. If I, a library consumer, were to answer the question what I would like Boost to be, that would be: 1. The certification role: to educate what a high standard library means, to offer help and tools for library developers to achieve this level (not necessarily as a Boost library) and to issue opinions on the libraries. Boost to a great extent already implements this. 2. To focus on foundational libraries: those that can help other libraries interoperate. Like the one big decimal library. An interesting counter example to using vocabulary types is Boost.JSON implementing its own string type for efficiency. I was already convinced that it was the right decision to implement a custom string. But it illustrates something important: we cannot have the one string class. I guess where there is a need to manage resources (like string manages memory internally) there cannot be the one vocabulary type. Regards, &rzej;

2 1