- Boost - lists.preview.boost.org

[PATCH] futex: fix build on 32-bit architectures using 64-bit time_t
by Khem Raj 21 Feb '22

21 Feb '22

Fix the following build failure on 32-bit architectures using 64-bit time_t (e.g. riscv32): | ./boost/fiber/detail/futex.hpp:31:23: error: use of undeclared identifier 'SYS_futex' | return ::syscall( SYS_futex, addr, op, x, nullptr, nullptr, 0); | ^ | 1 error generated. Signed-off-by: Khem Raj <raj.khem(a)gmail.com> --- boost/fiber/detail/futex.hpp | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/boost/fiber/detail/futex.hpp b/boost/fiber/detail/futex.hpp index e64bd5990..d0353e9e5 100644 --- a/boost/fiber/detail/futex.hpp +++ b/boost/fiber/detail/futex.hpp @@ -12,6 +12,10 @@ #include <boost/fiber/detail/config.hpp> +#ifndef SYS_futex +#define SYS_futex SYS_futex_time64 +#endif + #if BOOST_OS_LINUX extern "C" { #include <linux/futex.h> -- 2.35.1

1 0

unordered_map implementation
by Peter Dimov 19 Feb '22

19 Feb '22

I've been helping Christian Mazakas maintain Unordered, and we've been looking into trying to improve its performance on the synthetic benchmarks we have for it (https://github.com/boostorg/unordered/tree/develop/benchmark) One of the things that are hurting us is that we need to do a double indirection in order to find an element, because Unordered uses a singly-linked list for all its nodes, with the bucket array pointing at the element before the first one (in order to be able to support erasing.) There's also the option of using a doubly-linked list, which however increases the memory footprint. I'm looking at the iterator invalidation rules for std::unordered_map, and iterators are invalidated on every rehash. This makes me wonder why is it necessary to have all the elements in a single list, as every implementation seems to do. It seems to me that it's possible to just have singly- linked lists for each bucket, and then have a "fat" iterator that contains the bucket index and the pointer to the element. On increment, when the end of the bucket list is reached, the iterator can just go to the next non-empty bucket. Is there something I'm missing in the requirements that renders this implementation non-conforming?

2 2

std::launder and its usage in Boost
by Mikhail Kremniov 18 Feb '22

18 Feb '22

Hi, Initially, I posted this question to the boost-users list, but then I was advised to repost it here. I wonder, what is the Boost community's opinion of std::launder? In particular, of its necessity when accessing an object that was created via placement-new in an aligned_storage. As I can see, it's used by Boost.Beast in its implementation of the variant type, but not in other parts of Boost. The reason I'm asking this is that I'm working on a C++14 code-base that uses Boost.Variant and Boost.Optional extensively (as well as other parts of Boost that use Variant and Optional internally). Now we're trying to switch to C++17 at least, and I worry whether it could potentially break things. To put things into context, C++ standard states in the [basic.life] section that if you had an object and then created a new one in the same location, you can use the pointer to the old object to refer to the new one only if (among other things) "the new object is of the same type as the original object (ignoring the top-level cv-qualifiers)". This means, as I understand it, that it's technically illegal to reinterpret_cast the pointer to aligned_storage to the pointer to the actual type of the object created via placement-new, because placement-new has already ended the lifetime of the aligned_storage object. So, implementations of Boost.Optional and Boost.Variant are illegal then (?). But it's been like that since C++03 and Boost worked fine all that time, so it looks like this UB existed only "on paper". But C++17 then added "Note: If these conditions are not met, a pointer to the new object can be obtained from a pointer that represents the address of its storage by calling std::launder". So now the language has the ability to deal with that UB, and a question arises, is it possible that compilers could start to use the UB to perform additional optimizations and make it a real UB? Also, I've seen a couple of times on stackoverflow.com people saying that it's actually fine to reinterpret_cast the storage in C++14, but in C++17 it's not (they didn't explain why though). So, can switching from -std=c++14 to -std=c++17 be a breaking change when using Boost? The fact that Boost.Variant and Boost.Optional don't use std::launder - is it an oversight or a conscious decision? Regards, Mikhail.

5 18

Diagnostic improvements in 1.78/1.79
by Peter Dimov 15 Feb '22

15 Feb '22

This is a quick summary of some 1.78 and 1.79 changes in Assert, ThrowException, and System related to error reporting. In Boost 1.73, Assert acquired a new component, boost::source_location. This is a class encapsulating a source location (a collection of source file name, line number, column, and function name) that is modeled after C++20's std::source_location, except of course it doesn't require C++20. In 1.79, the macro that creates the current source location, BOOST_CURRENT_LOCATION, is now usable in a function default argument, similarly to std::source_location::current(). This enables functions to be declared like this: T& my_vector::at( size_t i, boost::source_location const& loc = BOOST_CURRENT_LOCATION ) { if( i >= size() ) { boost::throw_exception( std::out_of_range( "at" ), loc ); } return data_[ i ]; } Since functions such as `at` are called from many places in the program, it's more useful for the source location in the thrown exception to point at the call site, rather than inside of `at` (which doesn't provide much information.) See for example https://godbolt.org/z/6o9e187a1. Note that the location returned by diagnostic_information(x) points to line 35, which is the call to `v.at(5);` inside `main`. Recommendation one: add source_location default arguments to your throwing functions so that the information logged at the catch site points to the call that threw. In case you find boost::throw_exception too heavyweight, as it adds a boost::exception base class and support for boost::exception_ptr, and this would prevent you from applying the technique above, there is now an alternative function, boost::throw_with_location, in <boost/throw_exception.hpp>. It doesn't integrate with Boost.Exception or boost::exception_ptr, but does add a source location to the exception that can later be retrieved with boost::get_throw_location(x). The above example using boost::throw_with_location can be seen at https://godbolt.org/z/Pcj1xad3v. In 1.78, boost::system::error_code had also acquired support for source locations, although it's not as automatic as the above technique where the default argument automatically adds a location without the user needing to do anything. Since there's no space in error_code for the entire boost::source_location struct, it can only store a pointer to it. This requires the following incantation BOOST_STATIC_CONSTEXPR boost::source_location loc = BOOST_CURRENT_LOCATION; ec.assign( ENOENT, boost::system::generic_category(), &loc ); which can be wrapped in a macro. See the documentation of Boost.System: https://www.boost.org/doc/libs/1_78_0/libs/system/doc/html/system.html#usag… Unlike the case with exceptions, when working with error codes, the situation is reversed and we want to store the source location immediately after discovering the error, rather than the one of the user call that failed. That's both because this location gives the most information as to the source of the error (ENOENT on its own doesn't say much), and because error codes are generally checked close to the user call, so the call location isn't as useful. Recommendation two: add source locations to your error_codes if using Boost.System. Finally, when providing dual APIs, that is, APIs that can signal an error using both error_code or by throwing an exception, you can combine the above two approaches and store both the "deep" source location in the error_code and the "shallow" (user call) location in the system_error exception. I hope you find those useful. Further reading: https://www.boost.org/doc/libs/develop/libs/assert/doc/html/assert.html#sou… https://www.boost.org/doc/libs/develop/libs/throw_exception/doc/html/throw_… https://www.boost.org/doc/libs/develop/libs/system/doc/html/system.html

6 33

Proposed BoostBook fix for invalid <h7> and <h8> elements
by Evan Lenz 14 Feb '22

14 Feb '22

Hello, The DocBook stylesheets used by BoostBook occasionally will output invalid heading elements (<h7> or <h8>). Some (but not all!) areas of the stylesheets properly cap the output to <h6>. In particular, the rule for <bridgehead> fails to do this. The consequences are described in this BoostBook issue: https://github.com/boostorg/boostbook/issues/12 And (originally) in this issue in the docca tool, which depends on BoostBook: https://github.com/boostorg/docca/issues/79 I have created a pull request that fixes the DocBook issue by overriding the bridgehead rule. Although the ideal fix would be in the DocBook stylesheets themselves, these stylesheets are no longer being regularly updated. Also, my proposed fix conforms to the pattern of other BoostBook-specific stylesheet overrides. Is there someone familiar with BoostBook who would be willing to review my pull request (and raise any questions or concerns as desired)? https://github.com/boostorg/boostbook/pull/13 Thanks very much for your time! Evan Lenz

3 3

Building Boost, eventually
by Alain O' Miniussi 09 Feb '22

09 Feb '22

Hi, I finally got some time time to work on a Boost library and I am, as usual, fighting with bjam. === 14:58:08 [alainm@pollux boost]# ./bootstrap.sh --with-toolset=intel-linux Building B2 engine.. ... icpx (ICX) 2021.1 Beta 20200304 # why not icpc ? ... > icpx -x c++ -std=c++11 -O3 -s -static -DNDEBUG .... -o b2 ld: cannot find -lstdc++ ld: cannot find -lstdc++ === The problem here is the -static option, as libstdc++ is not available as an archive on linux (not on the ones I use). I submitted a fix, with no effect: https://github.com/bfgroup/b2/pull/133/files Also apparently some good soul (thank you!) started working on a CMake alternative that just work (checked twice). Its only issue is that the tests don't seems to have moved to CMake. So my question is: 1) Am I better off trying to port the testing of Boost.MPI to CMake and just forget about bjam or, 2) Try to invoke some demonic entity to get bjam working with intel-linux. What is the recommended build method recommended for libraries developers at this point ? Best regards ---- Alain Miniussi DSI, Pôles Calcul et Genie Log. Observatoire de la Côte d'Azur Tél. : +33492003009 (Mont-Gros) +33483618544 (Sophia Antipolis) +33609650665

3 4

boost::throw_exception potential changes
by Peter Dimov 07 Feb '22

07 Feb '22

Currently, `boost::throw_exception(x)` automatically throws an exception derived from `x` that (1) injects a boost::exception base class if there's none, and (2) injects a base class that enables boost::exception_ptr support (boost::current_exception and boost::rethrow_exception.) This is convenient, but the downside is the amount of generated code, e.g. https://godbolt.org/z/5T8T8GEqP (422 lines) compared to https://godbolt.org/z/1zr1odf7n (36 lines.) This is not the end of the world as this code is only generated once per exception type, not on every call to throw_exception, but it's still unpleasant to see. It so happens that boost::exception_ptr has recently acquired the ability to work under C++11 without the need for the supporting base class, by using the standard std::exception_ptr infrastructure. So if we also remove the automatic injection of boost::exception as a base class, and ask users to derive their exceptions from it if they desire having it as a base, it's possible to simplify boost::throw_exception considerably. The normal call now can be almost the same as the naked throw, https://godbolt.org/z/WssWzfrfW (47 lines.) And if BOOST_THROW_EXCEPTION is used, which still adds the source location (file/line/function) to the exception, the result is 97 lines. (https://godbolt.org/z/nETnqrsx8) However, there is a downside. Due to the way std::exception_ptr works under GCC/Clang (and all compilers using the same ABI), the exception is never copied, not when it's captured with std::current_exception (and consequently boost::current_exception), nor when it's rethrown with boost/std::rethrow_exception. This causes problems if an exception is captured, rethrown, caught and modified, then rethrown again using the same exception_ptr. The second rethrow throws the modified exception. This problem can be seen in https://godbolt.org/z/K9eh71ovP. So... what do we do? Should I go ahead with these changes to throw_exception (having a macro to revert to the old behavior, of course)? Or is that too much of a break? We can of course offer the same functionality as part of Boost.Exception, like boost::exception::raise, or similar, but would that be enough to offset the inconvenience?

4 11

[concept_check][ublas] Fixing deprecated copy warnings
by Antony Polukhin 07 Feb '22

07 Feb '22

Hi, There are two PR that fix deprecated copy warnings for GCC and Clang: * https://github.com/boostorg/concept_check/pull/35 * https://github.com/boostorg/ublas/pull/153 Please review those. They make the intent explicit and the code becomes more portable. Trivial sample that causes the warning https://godbolt.org/z/YaPvGfedv -- Best regards, Antony Polukhin

1 0

Primary test compilers in Boost release notes
by Peter Dimov 01 Feb '22

01 Feb '22

We have an issue, https://github.com/boostorg/boost/issues/610, that points out that the "Primary test compilers" section in the Boost 1.78 release notes is misleading, because it doesn't actually reflect whether a Boost library works with a specific compiler or not. The specific example cited is Multiprecision. The release notes say that on Linux, the following C++11 GCC compilers are "primary": GCC, C++11: 4.7.3, 4.8.5, 11 However, Multiprecision doesn't work with GCC 4.7.3 or 4.8.5, and likely never will, because these compilers do not actually implement the C++11 standard. (They don't implement reference qualified member functions and don't have a conforming <type_traits> header.) It would be better for everyone involved if the primary test compilers are somewhat aligned with (a) what Boost libraries actually support or require, and (b) what Boost libraries actually test with. The section historically lists what's in our test matrix, but nowadays most libraries depend on CI for testing, specifically on Github Actions (after the untimely death of open source Travis) and Appveyor. There's a fair bit of discussion in the linked issue above, but what I think is reasonable to list as primary test compilers as far as GCC is concerned is something like C++03: 4.8, 4.9, 5 C++11: 4.8(*), 4.9(*), 5 I would start with 4.8, because this is what GHA has on its 18.04 image. C++03 needs to have GCC up to 5 because this is the default -std level for these versions (GCC 6 is -std=c++14 by default), and the system- provided Boost is compiled with the default. 4.8 has enough of C++11 so it's possible for C++11 libraries to support it without much heroics, but we could go either way on this one, hence the asterisk.

2 1

[GSoC 2022] [Graph] Potential mentors
by Dev Jain 15 Jan '22

15 Jan '22

Hello everyone. I am Dev Jain, a sophomore student pursuing a Bachelors in Computer Science and Engineering from IIT Jammu. I am passionate about discrete mathematics, and in particular graph theory and graph algorithms. I would like to contribute to the Boost Graph Library. I can't find any project ideas for the BGL in recent years of GSoC. Are there any people active with BGL, and any prospective mentors? I understand that, it is recommended to come to the mailing list asking for mentors by describing an idea, but I wanted to ask this since for many years a BGL project hasn't been proposed in the ideas list. Thanks.

1 0