October 2025 - Boost - lists.boost.org

[boost][decimal] Andrzej's review
by Andrzej Krzemienski 13 Oct '25

13 Oct '25

Hi Everyone, This is a review of the Boost.Decimal library. My knowledge about decimal floats is very superficial. In my job I need to deal with prices in all the World's currencies (string<->numeric conversion and simple additions and scaling) and for that I use a home-brew fixed-point implementation. I participated in the previous review, spent a couple of days studying the documentation, having a superficial look at tests and small pieces of implementation, running simple examples and filing bug reports. I would like to thank Matt and Chris for the huge effort to write and maintain this library, and for undergoing the painstaking process of Boost Review. The community needs this library, and I am happy that it is proposed for Boost. The nature of this library is very unusual: it implements types that belong in processors. We know it is needed for applications where accuracy and correctness is absolutely critical. Against other Boost libraries, it requires extreme measures for verifying correctness across the whole spectrum of values and cases. In a similar vein, in my opinion, it requires extremely detailed and comprehensive documentation. The bar should be higher than for an average Boost library. In this context, I have some concerns. While playing with the library I found three corner cases where it produces incorrect results: * https://github.com/cppalliance/decimal/issues/1091 * https://github.com/cppalliance/decimal/issues/1094 * https://github.com/cppalliance/decimal/issues/1119 Two are already fixed, and Matt has been very responsive, but I feel like it is too easy for a novice to find bugs in the library after a couple of minute's tests. It looks to me like the unit test "sieve" is still too coarse. Some test files (like test_decimal32.cpp or test_decimal64_basis.cpp) are commented out. Fuzz tests for decimal comparisons in random_decimal32_comp.cpp seem to be only testing decimals created from integer values (no fractions). I know that other Boost candidate libraries pass with fewer tests, but I feel this one needs to have a lot of them. I am not even sure how one tests user-defined literals across the spectrum. Maybe the unit tests should be written outside of C++. One can see that a lot of work went into preparing the documentation. It is helpful and already provides a lot of useful information, also about the background, and ideas. It has the "Design Rationale" section which reminds me of the high quality documentation that the original Boost libraries used to have. But I still find it insufficient. The API reference for the key types, like `decimal32_t`, only lists the class members, but there is no detailed description for the behavior of these members. What are the preconditions of the Decimal's constructors? Is any combination of values considered invalid? Or is it nicely degrading to subnormals and infinities? I think the contract of the library (how the cohorts are treated in comparisons, if they are implementation detail, or are observable?) need to be spelled out more clearly. Again, Matt has been very responsive, and the documentation has improved a lot during the review period, and I know it will improve further. Regarding the design, it looks like it has been done by IEEE, so not much to review here. I only had a short glimpse at the implementation, so I cannot say much. One thing that I found surprising is that operator<=> is implemented in terms of operators <, > and ==. Operator <=> was designed for the class authors to go the opposite way: define operator <=> and you get all the others for free. So I wonder what was the reason for the current implementation. I do not feel comfortable giving an accept or reject recommendation. I clearly have a higher acceptance bar for this library than for any other I have seen reviewed in Boost, and this may appear unfair. Do I want to see this library in Boost? -- yes. It is useful, and IEEE seems to agree. Are the authors the right people to implement it? -- definitely! But I would feel more comfortable accepting it, if it went through another review iteration. Could this be considered a conditional acceptance? In the case of the test sieve issue I brought up, I do not think it is a question of writing more tests. It is more a question of designing an approach to testing that would give a guarantee of correctness. This is requesting a lot of work from the authors who already put a lot of effort to get the library where it is. It is huge (both the library and the effort)! Again, this cannot be overstated. Matt and Chris: you did great work! Thank you! I know that sooner or later we will be able to use Boost.Decimal from the official distribution. Also, thanks to John Maddock for managing the review. Regards, &rzej;

3 3

Master regression tests failing
by Tom Kent 12 Oct '25

12 Oct '25

There seems to be a problem on master with all tests failing. It results in this in the log: error: Unable to find file or target named error: '/var/boost/run/boost_root/libs/system/build//boost_system' error: referred to from project at error: '../libs/graph_parallel/test' error: could not resolve project reference '/var/boost/run/boost_root/libs/system/build' Tom

4 4

[charconv] Possible bug
by Gennaro Prota 10 Oct '25

10 Oct '25

Hi, the following program prints "1e-01". Furthermore, it prints "Error: 132" if I change `size` to 20. It prints the expected "0.1" if I change the two using declarations to use the standard facilities. Tested against the master branch, with MSVC 2022. Is this a bug in CharConv? #include "boost/charconv.hpp" #include <charconv> #include <iostream> int main() { // using std::to_chars; // using std::chars_format::general; using boost::charconv::to_chars; using boost::charconv::chars_format::general; int const size = 100; char buffer[ size ]; auto const r = to_chars( buffer, buffer + size, 0.1, general ); if ( r.ec != std::errc() ) { std::cerr << "Error: " << static_cast< int >( r.ec ) << std::endl; return 1; } *r.ptr = '\0'; std::cout << buffer << std::endl; } -- Gennaro Prota <https://prota.dev>

2 1

[container] New deque implementation and future plans
by Ion Gaztañaga 10 Oct '25

10 Oct '25

Hi, I've been working lately on a new deque implementation for Boost.Container. The original uses the classic SGI STL-based data structure, that is quite bulky. The new implementation is already on develop and ready to be merged to master for Boost 1.90 The new implementation will try to be faster than std implementations (I probably need to work more on that with benchmarks), but more importantly, can allow some additional features. Some changes: - sizeof(deque) was 10 words, now is 4 words. Probably the lightest implementation around. - sizeof(deque::iterator) was 4 words, now is is 2 words (similar to libc++ and MSVC).) - Several internal algorithms were reimplemented to take advantage of the segmented nature of deque. - Defaults were slightly changed, 64 bit platforms now use 1024 byte blocks by default instead of the SGI classic 512 byte blocks (still far from libc++'s 4K blocks). - The new implementation eases further deque-like variations and optimizations in the future. Some planned features - Add a "stored_size_type" option so that the sizeof deque can be further decreased (probably down to 3 words) for those in 64 bit platforms that don't need more than 4G elements in deque. - Add a single-ended variation ("seque" might be confusing name because the data structure would not longer be a queue, but a segment-based sequence with random-access). Some people use deque to have a random-access container that avoids vector-like reallocations and guarantees stable pointers and references when inserting on the back. A double-ended container is sometimes sub-optimal for those use cases. - Add options (or maybe different containers or aliases reusing parts of the implementation) that can offer "reserve/capacity"-like features, so that a programmer can pre-allocate all the blocks that's going to use avoiding allocation performance penalties on hot code. I'll update the "Draft Development Plan for Boost.Container" (https://docs.google.com/document/d/1VdMTheFUczC946dP3VKPseOoUq3sVKjU73oMvK8…) with these proposals. Of course, I'm open to new proposals/features. If any booster is eager to test the new deque implementation or wants to suggest a benchmark/use-case that could be useful for Boost.Container users, please let me know! If anyone detects a bug in the new implementation please notify it and I'll try to solve it ASAP. Best, Ion

6 10

[static_string] Removing support for BOOST_STATIC_STRING_STANDALONE?
by Gennaro Prota 09 Oct '25

09 Oct '25

Hi, while discussing a PR on GitHub (<https://github.com/boostorg/static_string/pull/67>), we ran into the question of whether BOOST_STATIC_STRING_STANDALONE should still be supported. What's your take on it? Personally, I lean toward minimizing conditional compilation wherever possible. Also, the macro is used to avoid dependencies which are easily avoided anyway, so why not avoiding them unconditionally and have "standalone mode" as the only option? -- Gennaro Prota <https://prota.dev>

5 6

A string_view with null-terminator guarantee?
by Andrzej Krzemienski 07 Oct '25

07 Oct '25

Hi Everyone, Would Boost libraries benefit from having a string_view-like type with the guarantee that the underlying character sequence is null-terminated? This could be as yet another Boost library, or as part of Boost.Core. Maybe Boost already has such a type somewhere? The need for such a type surfaces time and again. When a library needs to be passed both const char * and std::string cheaply, only to pass it down to low-level C-libraries later. We have seen one recently during the review of Boost.Sqlite. One is again proposed for standardization: wg21.link/p3655. Regards, &rzej;

16 40

Minimum CMake version raised to 3.8
by Alexander Grund 02 Oct '25

02 Oct '25

Hi maintainers, the Boost superproject build now requires CMake 3.8 or higher. The reason for this is that the CMake feature `cxx_std_11` to declare the C++11 requirement was introduced in that version and is now used by a large amount of libraries, directly or indirectly. This change [1] was made due to users being confused about which CMake versions are required/supported (e.g. [2]). A couple libraries failed to declare the CMake 3.8 requirement even though they were using `cxx_std_11` leading to error messages that were not easy to understand to someone not used to CMake. I opened PRs fixing the requirements in a couple of repositories which I discovered during testing with a range of different CMake versions. Raising the minimum version to 3.8 reduces the number of versions to be tested with a low enough cost given the actual requirement by the many individual libraries and availability of that version (3.8 is old enough that it should be easily available to users, current versions are 3.31 and 4.1.) Note that some features of the Superproject require even higher versions: - BoostTestJamfile requires 3.9 - Automatic installation requires 3.13 So users should be using at least CMake 3.13 anyway. Stay safe! Alex [1] https://github.com/boostorg/boost/pull/1088 [2] https://github.com/boostorg/boost/pull/1081

1 0

[bloom] added bulk operations
by Joaquin M López Muñoz 01 Oct '25

01 Oct '25

For those interested in Boost.Bloom, I've just added bulk operations, which will make it into Boost 1.90: https://43.bloom.prtest3.cppalliance.org/libs/bloom/doc/html/index.html#tut… <https://43.bloom.prtest3.cppalliance.org/libs/bloom/doc/html/index.html#tut…> Joaquín M López Muñoz

2 2