- Boost - lists.boost.org

[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

Boost.URL -- some notes
by Andrzej Krzemienski 11 Jun '22

11 Jun '22

Hi Everyone, I am trying to do a review of Boost.URI library (I usually find the official ten-day review period to be too short), and there are a number of interesting things I came across that I thought I would mention. The docs say: > The library requires Boost and a compiler supporting at least C++11. > Even though the library is a candidate for a Boost library, I understand that it is now offered as a "stand alone" version, and this is what the docs describe. I tried to use it with the latest MinGW Distro on Windows ( https://nuwen.net/mingw.html) which uses GCC 11.2 and Boost 1.77. Without success. This is because Boost.URL relies on the component boost::system::result<T>, which is present in Boost.System only since version 1.78: https://www.boost.org/doc/libs/1_79_0/libs/system/doc/html/system.html#chan… First, this is news to me that we have `result<T>` in Boost.System, which has an overlap with result<T, E> from Boost.Outcome. Second, I recommend that Boost.URL docs say that it requires Boost 1.78 or higher. Next, we read: Aliases for standard types, such as string_view > <https://master.url.cpp.al/url/ref/boost__urls__string_view.html>, use > their Boost equivalents. > After reading this, I expected that Boost.URL would use boost::string_view from Boost.Utility library: https://www.boost.org/doc/libs/1_79_0/libs/utility/doc/html/utility/utiliti… But instead, it uses boost::core::string_view, which is an implementation detail from Boost.Core library: https://github.com/CPPAlliance/url/blob/master/include/boost/url/string_vie… Again, this is news for me that Boost has two implementations of string_view. Why? Second, I do not think that Boost.URL should rely on the implementation details of Boost.Core. A better alternative would be to use the official boost::string_view from Boost.Utility. Or is there a good reason not to? Next, the section on the parsers ( https://master.url.cpp.al/url/parsing/url.html) describes the function parse_uri() which returns result<url_view>. What strikes me is this difference: URI (Identifier) in the function name, and URL (Locator) in the return type. I always used the terms URL and URI interchangeably. But now that I see them used in this way in a well designed library, it looks disturbing. The quoted rfc3986 ( https://datatracker.ietf.org/doc/html/rfc3986#section-1.1.3) says that an URL is a subset of URI. Now, the name `parse_uri` implies that it will recognize any URI, but on the other hand it is impossible that the result will fit into a url_view, because not every URI is an URL. The synopsis for parse_uri ( https://master.url.cpp.al/url/ref/boost__urls__parse_uri.html) says: Exception safety: throws nothing. > And the line below it says that the function throws std::length_error when the input is too long. It looks like a bug in specs. Later we read: Return value: A result containing the view to the URL, or an error code if > the parsing was unsuccessful. > Which is not precise enough to give me the answer to the URI-vs-URL question. When can a parsing be non-successful? Is it only because it was not conformant to the grammar? The synopsis says "This function parses a string according to the URI grammar below", but is it a URI grammar or a URL grammar actually? Maybe the "return value" section should say instead: Return value: A result containing the view to the URL, or an error code if > the contents of `s` were not conformant with the above grammar. > That is, any other reason for not being successful (if any resources needed to be allocated and failed) may still be reported via exceptions. Now, there is probably a good explanation to the URI vs URL discrepancy. I think it would be good if it was placed in the docs, so that the users don't get confused. While this might look like a list of complaints, I really appreciate the efforts the authors put in creating this library and its documentation. The documentation is really high quality, way higher than the average you will find in GitHub. And this is actually because of this high quality that I am able to spot and report these issues. Regards, &rzej;

11 24

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

how to build boost 1.79 with "clang-cl" under Windows?
by Dennis Luehring 05 Jun '22

05 Jun '22

i've got a working LLVM 14.x/clang-cl installation (means working with cmake/ninja etc. with my non boost projects) and working boost builds for 32/64 bit with VS2017,2019,2022,mingw aka a "good working environment" for my boost projects i tried to use my VS2017 built libs by forcing the toolkit name with set(Boost_COMPILER "vc141") in my root CMakeLists.txt cmake -G Ninja -DCMAKE_C_COMPILER="C:/Program Files/LLVM/bin/clang-cl.exe" -DCMAKE_CXX_COMPILER="C:/Program Files/LLVM/bin/clang-cl.exe" ../myproject that does not work for all linking (sometimes lld-link.exe complains about missing libboost_unit_test_framework-clangw14-mt-gd-x64-1_79.lib etc. (with the wrong "clangw14" in the name) im always using boosts own cmake configuration using the CONFIG parameter with cmakes find_package find_package(Boost CONFIG REQUIRED COMPONENTS unit_test_framework filesystem system) and i've checked that Boost_COMPILER is always "vc141" before find_package call do i miss something or does Boost_COMPILER does not work properly with boost own cmake config ? the other idea was to build boost directly with clang-cl in an VS2017 build environment inside my current boost build folder (where are the lib32-msvc-14.1, lib64-msvc-14.1 etc. b2 build folders resist) i tried to build with toolkit=clang without and beeing in a VS2017 build environment with C:\Program Files\LLVM\bin in my path using that b2 commandline for building b2 -j%NUMBER_OF_PROCESSORS% toolset=clang address-model=64 --stagedir=.\lib64-clang-14.0 --build-dir=.\__build --build-type=complete threading=multi architecture=x86 stage --with-date_time --with-graph --with-nowide --with-test --width-config --with-system --with-filesystem --with-serialization but that fails with linker errors (https://docs.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tool…) any tutorial how to force building boost with clang-cl instead of cl using the microsoft libraries etc. as usual? there is no clang-cl or clangw toolkit setting available to my understanding

2 5

Boost.Locale will require C++11
by Alexander Grund 03 Jun '22

03 Jun '22

Quick announcement: I'm planning on dropping C++98 support for Boost.Locale. I.e. require e.g. Rvalue references and std::unique_ptr to reduce maintenance effort. If anyone knows a reason to not do that please respond to https://github.com/boostorg/locale/issues/90 As per suggestion from Peter I'll add a warning for the upcoming release and will drop support in the next if there isn't anything in particular. Especially recent ICU headers already requiring C++11 is enough of a reason to not stick to the old stuff. Regards

1 0

Something has broken quickbook build
by John Maddock 03 Jun '22

03 Jun '22

I can't spot where, but something has changed in the last couple of days that has broken building quickbook: https://app.circleci.com/pipelines/github/boostorg/math/635/workflows/33cd9… ../../../boost/container_hash/hash.hpp:654:30: error: call of overloaded 'hash_value(const boost::filesystem::path&)' is ambiguous 654 | return hash_value( val ); | ~~~~~~~~~~^~~~~~~ ../../../boost/container_hash/hash.hpp:382:9: note: candidate: 'typename boost::enable_if_<((boost::hash_detail::is_range<T>::value && (! boost::hash_detail::is_contiguous_range<T>::value)) && (! boost::hash_detail::is_unordered_range<T>::value)), long unsigned int>::type boost::hash_value(const T&) [with T = boost::filesystem::path; typename boost::enable_if_<((boost::hash_detail::is_range<T>::value && (! boost::hash_detail::is_contiguous_range<T>::value)) && (! boost::hash_detail::is_unordered_range<T>::value)), long unsigned int>::type = long unsigned int]' 382 | hash_value( T const& v ) | ^~~~~~~~~~ In file included from /root/boost-local/boost/tools/quickbook/src/files.hpp:18, from /root/boost-local/boost/tools/quickbook/src/files.cpp:10: ../../../boost/filesystem/path.hpp:1183:82: note: candidate: 'typename boost::enable_if<boost::is_same<T, boost::filesystem::path>, long unsigned int>::type boost::filesystem::hash_value(const T&) [with T = boost::filesystem::path; typename boost::enable_if<boost::is_same<T, boost::filesystem::path>, long unsigned int>::type = long unsigned int]' 1183 | inline typename boost::enable_if< boost::is_same< T, path >, std::size_t >::type hash_value(T const& p) BOOST_NOEXCEPT In point of fact, those two overloads do look genuinely ambiguous to me, so I'm not sure why this compiled before, or what changed to make it fail now? Ideas? Thanks, John.

2 1

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