- Boost - lists.boost.org

The deadline for new libraries and breaking changes in Boost 1.80.0 is June 22
by Glen Fernandes 16 Jun '22

16 Jun '22

2022-06-22 closed for new libraries and breaking changes in Boost 1.80. See https://www.boost.org/development/index.html for the full calendar. - The Release Managers

1 0

Boost.MySQL naming
by Ruben Perez 14 Jun '22

14 Jun '22

Hi all, We have received an answer from Oracle's legal team, thanks to Norvald, who initially wrote in this ML and works for Oracle. TL;DR: Boost.MySQL keeps its name. > Naming the library as proposed (Boost.MySQL) is not a problem for a > community connector to MySQL. This is consistent with other naming we > see in the MySQL community and in our experience it has not caused > confusion. We would be concerned about any naming or statements that > suggest an inaccurate association between your library or product and > MySQL, but that does not appear to be the case. So I'm afraid we won't be having Boost.OurSQL anytime soon. Regards, Ruben.

1 0

[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