November 2023 - Boost - lists.preview.boost.org

[scope] Scope review starts on November 26th
by Дмитрий Архипов 07 Dec '23

07 Dec '23

Dear Boost community. The peer review of the proposed Boost.Scope will start on 26th of November and continue until December 5th. Boost.Scope is a small library implementing utilities defined in <experimental/scope> from C++ Extensions for Library Fundamentals v3 with a few extensions. Namely, the library contains: * A number of scope guards for various use cases. * A unique resource wrapper that automatically frees the resource on destruction. * Utilities for wrapping POSIX-like file descriptors in the unique resource wrapper. You can find the source code of the library at https://github.com/Lastique/scope and read the documentation at https://lastique.github.io/scope/libs/scope/doc/html/index.html. The library is header-only and thus it is fairly easy to try it out. In addition, the library can be used with Conan and vcpkg (see its README for instructions on how to do that). Finally, there's a single header version suitable for Compiler Explorer (https://raw.githubusercontent.com/Lastique/scope/single-header/include/boos…). As the library is not domain-specific, everyone is very welcome to contribute a review either by sending it to the Boost mailing list, or me personally. In your review please state whether you recommend to reject or accept the library into Boost, and whether you suggest any conditions for acceptance. Thanks in advance for your time and effort! Dmitry Arkhipov, Staff Engineer at The C++ Alliance.

16 83

Master branch is now open for bug fixes
by Marshall Clow 06 Dec '23

06 Dec '23

The master branch is now open for bug fixes and documentation changes. Other changes by release manager permission, as described in https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy The next deadline: On December 6th, master closes for all changes. As always, the calendar is at https://www.boost.org/development/ — Marshall

10 23

Proposal for Inclusion of Async.MQTT5 Library in Boost
by Ivica Siladic 05 Dec '23

05 Dec '23

Dear Boost Developers, we are writing to introduce a new C++ Async.MQTT5 library that we believe would be a valuable addition to Boost. MQTT has become the de-facto standard for IoT communication, with billions of IoT devices relying on it to publish or retrieve data from the cloud. Despite its widespread use, integrating MQTT into a C++ embedded application remains a complex and error-prone task. This challenge primarily arises from the absence of a higher-level library that offers a straightforward interface for message publishing and receiving while abstracting MQTT protocol intricacies and effectively managing various corner cases inherent in MQTT implementation. The primary objective behind developing Async.MQTT5 was to address these challenges comprehensively, allowing developers to focus on the messages they need to send without concerns about underlying network connectivity issues. Async.MQTT5 is a C++20 client implementation of the MQTT 5.0 protocol, leveraging Boost Asio and Boost Spirit. It fully adheres to the Asio asynchronous model, providing comprehensive support for all forms of asynchronous completion tokens, per-operation cancellation, and custom allocators. The library is designed to work seamlessly with any ordered network transport, typically TCP, SSL/TLS over TCP, or WebSockets (secured and unsecured). Our goal with Async.MQTT5 is to offer developers a simple and clear C++ interface for sending and receiving messages using the MQTT 5.0 protocol. Emphasizing code readability was a key design principle of Async.MQTT5. For instance, tedious protocol message parsing/composing is implemented declaratively (partially utilizing Boost Spirit). Additionally, Asio composed operations are implemented using a novel, clear, and highly efficient "chaining functional operators" approach. It is worth noting that the library is already written following Boost style guidelines, and the documentation is crafted and formatted in line with Boost conventions. You can find the library at https://github.com/mireo/async-mqtt5, and the documentation is available at https://spacetime.mireo.com/async-mqtt5/. We highly value your opinion and would appreciate any feedback you can provide on the Async.MQTT5 library. Thank you for your time and consideration. Best regards, Ivica Siladic Bruno Iljazovic Korina Simicevic

9 15

[scope] A few questions
by Julien Blanc 05 Dec '23

05 Dec '23

Hi, I have a few questions regarding the scope library currently being reviewed: * scope_exit is not default constructible. But it can be released and is movable, so a default constructed scope_exit state makes sense (this is the same as a moved-from scope_exit). I find this a rather strange design choice. What is the rationale behind this? There's even a section on the documentation on how to circumvent this: https://lastique.github.io/scope/libs/scope/doc/html/scope/scope_guards.htm… using cleanup_func_t = std::function< void() >; // Create an inactive scope guard first, since the cleanup function is not set yet boost::scope::scope_exit< cleanup_func_t > cleanup(cleanup_func_t(), false); Why can't i just write? boost::scope::scope_exit< std::function< void() > > cleanup; * the documentation says little about memory allocation. I finally found the answer i was looking for in the boost.ScopeExit comparison: scope_xxx objects do not do any heap allocations themselves. Is that a guarantee of the library? Such a guarantee is needed in some code i work with, i need to know if it is a feature of the library that i can rely upon, and not just an optimization that could go away in a further release. * unique_fd is a resource wrapper for files. But on all major systems, closing a file can fail and return an error. It may well be that the file is not completly written correctly, and this is reported not in the write call, but in the final close call. unique_fd silently drops the return value of close. I'm not sure we should encourage this behaviour. Another issue raises when we look at the example code: void write_string(std::string const& filename, std::string const& str) { // Create a unique resource for a file boost::scope::unique_resource< int, fd_deleter > file(open(filename.c_str(), O_CREAT | O_WRONLY)); if (file.get() < 0) { int err = errno; throw std::system_error(err, std::generic_category(), "Failed to open file " + filename); } // Use it to write data to the file const char* p = str.data(); std::size_t size_left = str.size(); while (size_left > 0) { ssize_t written = write(file.get(), p, size_left); if (written < 0) { int err = errno; if (err == EINTR) continue; throw std::system_error(err, std::generic_category(), "Failed to write data"); } p += written; size_left -= written; } } In case of a failure, what we got is an half-baked file, which we know nothing about. A proper write_string function should at least try to do its cleanup and delete the file in case of error. But that defeats the purpose of unique_resource... In my experience, automatically closing file handles is not error handling. But it has its use cases, maybe it would be better demonstrated by an example like: bool compare_files(std::string const& filename1, std::string const& filename2) { boost::scope::unique_resource< int, fd_deleter > file1(open(filename.c_str(), O_CREAT | O_WRONLY)); if (file1.get() < 0) { int err = errno; throw std::system_error(err, std::generic_category(), "Failed to open file " + filename1); } boost::scope::unique_resource< int, fd_deleter > file2(open(filename.c_str(), O_CREAT | O_WRONLY)); if (file2.get() < 0) { int err = errno; throw std::system_error(err, std::generic_category(), "Failed to open file " + filename2); } // do the comparison } Regards, Julien

2 7

Re: [boost] [scope] Scope review starts on November 26th
by Janko Dedic 02 Dec '23

02 Dec '23

Thanks for proposing this library. Scope guards are a natural and much needed addition to Boost. The following is my review of the proposed Boost.Scope. The first thing I looked for in this library was a convenience SCOPE_EXIT { ... }; macro that would provide the functionality in the form of a control flow construct. I've managed to quickly find it, but it wasn't exactly what I was expecting. BOOST_SCOPE_FINAL [] { std::cout << "Hello world!" << std::endl; }; I found it rather odd that the capture list is not included in the macro. I looked a bit further into the documentation to find this: BOOST_SCOPE_FINAL std::ref(cleanup_func); Is this use case the reason why the capture list is required? It seems like a very rare one that shouldn't pessimize the interface for 99% of use cases. Performance shouldn't be a concern because the compiler sees all this code and inlines it anyway. In my view, this just makes the interface worse and less pleasant to use. scope_success doesn't seem terribly useful. I have yet to see a legitimate use case of this type. I haven't found a motivating example in the documentation. There should either be one, or this type should be removed from the library. There is no BOOST_SCOPE_FAIL macro. Why is it missing? I found the scope_fail example pretty bad: class collection { std::set< std::shared_ptr< object > > objects; public: void add_object(std::shared_ptr< object > const& obj) { // Create a deactivated scope guard initially std::set< std::shared_ptr< object > >::iterator it; boost::scope::scope_fail rollback_guard{[&, this] { objects.erase(it); }, false}; bool inserted; std::tie(it, inserted) = objects.insert(obj); if (inserted) { // Activate rollback guard rollback_guard.set_active(true); } obj->on_added_to_collection(*this); } }; It could be simply rewritten to not use set_active (which should be discouraged, because it makes code less declarative and harder to follow): class collection { std::set< std::shared_ptr< object > > objects; public: void add_object(std::shared_ptr< object > const& obj) { // Create a deactivated scope guard initially std::set< std::shared_ptr< object > >::iterator it; bool inserted; std::tie(it, inserted) = objects.insert(obj); if (inserted) { boost::scope::scope_fail rollback_guard{[&, this] { objects.erase(it); }}; obj->on_added_to_collection(*this); } } }; Could be made even cleaner by using an early return: if (!inserted) return; All destructor declarations in the documentation lack noexcept specification, which by default means that they're noexcept, but they're actually not if you look at the Throws section, or the implementation. Also, the question presents itself: why are these destructors allowed to throw? I feel like it is common knowledge today that destructors should not throw, and this is heavily frowned upon. I can see the want to "be generic" here, but I don't see why a library should entertain broken code. I also noticed that certain scope guards are move constructible. Why? I cannot imagine myself ever approving of someone moving a scope guard on code review. Scope guards are to be used exclusively as local variables and don't need to be moved. This just opens up room for misuse. I don't see any compelling use cases for scope_exit::set_active in the documentation. The only example I find motivating is this one: void push_back(int x, std::vector<int>& vec1, std::vector<int>& vec2) { vec1.push_back(x); // Revert vec1 modification on failure boost::scope::scope_exit rollback_guard{[&] { vec1.pop_back(); }}; vec2.push_back(x); // Commit vec1 modification rollback_guard.set_active(false); } This could as well have used rollback_guard.release();. This matches my personal experience: only dismiss/release/cancel is necessary for real use cases ("commiting" something and thus disabling the "rollback" action). absl::Cleanup for example, supports only Cancel(). There is value in preventing users from shooting themselves in the foot. I don't like the name scope_exit::release personally. I feel like "dismiss" or "cancel" would be much better. I know that std::experimental::scope_exit calls it "release", but we shouldn't appeal to false authority. I did not like the locked_write_string example. Reading this code locally: // Lock the file while (flock(fd, LOCK_EX) < 0) { err = errno; if (err != EINTR) return; } it's hard to get what's happening, why we're setting err and how big of an impact that has on function behavior. A better way to write this code would be to simply extract this piece into its own function: err = errno; if (err != EINTR) return; together with the ec = std::error_code(err, std::generic_category()), which doesn't require a scope guard. fd_deleter and unique_fd provide some nice handling for EINTR, which wasn't required but I think it's nice to have and it's good that it's a part of this library! I think make_unique_resource_checked approaches the problem from the wrong direction. This code: // Create a unique resource for a file auto file = boost::scope::make_unique_resource_checked( open(filename.c_str(), O_CREAT | O_WRONLY) -1, fd_deleter()); if (!file.allocated()) { int err = errno; throw std::system_error(err, std::generic_category(), "Failed to open file " + filename); } could be this: // Create a unique resource for a file int file = open(filename.c_str(), O_CREAT | O_WRONLY); boost::scope::scope_final close_file(fd_deleter{}); if (file != -1) { int err = errno; throw std::system_error(err, std::generic_category(), "Failed to open file " + filename); } This has the advantage of being able to use `file` directly for the rest of the code instead of `file.get()`. I think a similar utility would be more useful in form of a class template, for example: resource<HANDLE, INVALID_HANDLE_VALUE, ::CloseHandle> windows_handle; resource<SDL_Window*, nullptr, ::SDL_DestroyWindow> sdl_window_handle; This would be very useful for concisely implementing RAII wrappers over C handles (you don't have to manually write destructors, move constructors and move assignment operators). For local use (within a function), I feel like a local handle + scope guard is just more ergonomic than the whole make_unique_resource_checked thing. My overall impression is that this library is trying to be too generic when it's not really necessary. There's definitely useful stuff here that I want to see included, but also a lot of stuff that is too much. I don't personally see the need for any scope guard beyond scope_exit with a release. That covers all the use cases I've ran into very nicely. scope_fail can be more error-prone since the "commit" is not explicit, so you may end up doing rollback even when it's unnecessary. Using the modified example from the documentation: void push_back(int x, std::vector<int>& vec1, std::vector<int>& vec2) { vec1.push_back(x); // Revert vec1 modification on failure boost::scope::scope_fail rollback_guard{[&] { vec1.pop_back(); }}; vec2.push_back(x); do_something_else(); // if this throws, rollback_guard runs } If you use scope_exit with an explicit release, it's clearer IMO: void push_back(int x, std::vector<int>& vec1, std::vector<int>& vec2) { vec1.push_back(x); // Revert vec1 modification on failure boost::scope::scope_exit rollback_guard{[&] { vec1.pop_back(); }}; vec2.push_back(x); rollback_guard.release(); // commit do_something_else(); // if this throws, rollback_guard won't run } The documentation states that "exception_checker is incompatible with C++20 coroutines", which is true in general, but it doesn't have to be (depending on the coroutine library implementation). However, I bring this up because using scope_exit+release is an entirely viable alternative for coroutines. scope_exit+release will work whether you use exceptions, error codes, std::expected, coroutines or all of them combined. This is the beauty of it, which makes me feel like scope_fail is unnecessary. I vote to ACCEPT this library with the following CONDITIONS: - BOOST_SCOPE_FINAL includes the lambda capture list OR another macro that does is provided; - noexcept specification on destructors is properly documented; - move constructors on all scope guard types are deleted; - a motivating example for scope_success is provided, or the type is removed. These are my conditions, but I'm hoping the full review is taken as a recommendation in improving the library and the documentation. Best regards, Janko Dedic

3 18

Boost Culture
by Vinnie Falco 02 Dec '23

02 Dec '23

It occurs to me that newcomers to the mailing list will not have any understanding of Boost culture or its development process. For example there is a recurring theme where a new person will ask about "what documentation toolchain does Boost use." The answer of course is that every library has considerable autonomy to define how it wants to generate its documents. The only requirement is that the final result is rendered as HTML. Another example is the idea that there is a "CEO of Boost." Or rather that there are particular individuals who have some sort of decision-making authority for the entire libraries. Or another example, why we use mailing lists over dedicated forum software. We might consider putting together a document which centralizes all of the collected wisdom and knowledge about Boost culture including the history of its evolution and why some things are the way that they are. This would facilitate the entry of newcomers to places like the mailing list which assume that participants already know a lot about Boost culture. This could become a chapter in the new Contributor Guide: https://www.preview.boost.org/doc/contributor-guide/index.html Thanks

4 3

[scope] Scope review starts on November 26th
by Claudio DeSouza 28 Nov '23

28 Nov '23

It would be helpful if the cmake build was fixed to not require some specific custom setup that was used by the author during development. The cmake list file seems to check for the existence of a cmake test file, to decide whether or not to build the tests. These files seem to have been moved outside reach of the setup in place, under test/test_cmake. Also, it would be better to get rid of this: add_subdirectory(../../../.. "${CMAKE_CURRENT_BINARY_DIR}/boost_superproject") Ideally, these cmake tests should assume scope is a submodule, or a subfolder, of the boost super project. Claudio.

4 3

[release] Boost 1.84.0 beta 1 released
by Marshall Clow 24 Nov '23

24 Nov '23

Boost release 1.84.0 beta 1 is now available at: https://boostorg.jfrog.io/artifactory/main/beta/1.84.0.beta1/source/ The SHA256 checksums are: 224d595cc666c19b91214c5e9cced3988d08063146dfad9f616c481d52626f27 boost_1_84_0_b1.zip de9b35e232e4b1769f4d800ec01255a9c2546639be43e45b16ce6d109c088e99 boost_1_84_0_b1.tar.gz f8a9f21580961536a95fb7fcf9deebde45d7e0e94ddd81402f1e37ae2c590410 boost_1_84_0_b1.tar.bz2 3e4765c41974c763b7d4a67a432569bf75d3367d7a6b72c4ac9458e5004c59dc boost_1_84_0_b1.7z Release notes (still need updates): https://www.boost.org/users/history/version_1_84_0.html Please try the beta and report any problems you encounter. Thanks to everyone who contributed to the release. -- Boost Release Team

3 3

cobalt build is failing
by Alain O' Miniussi 24 Nov '23

24 Nov '23

Hi, The colbalt build fails on master, starting with this message: [...]/boost/libs/cobalt/test/main.cpp:10:21: error: too few arguments to function call, expected 2, have 1 boost::cobalt::main co_main(int argc, char *argv[]) ^~~~~~~ I can provide more details if needed, but first I'd like to know if this is expected. Thanks ---- Alain Miniussi DSI, Pôles Calcul et Genie Log. Observatoire de la Côte d'Azur Tél. : +33609650665

2 2

[1.84][beast] Permission to merge to master
by Mohammad Nejati [ashtum] 17 Nov '23

17 Nov '23

Hi, I’d like to merge this to master: https://github.com/boostorg/beast/compare/master...develop Fixes a narrowing conversion error reported in this issue: https://github.com/boostorg/beast/issues/2766 Thanks, Mohammad Nejati

2 1

[release] Boost 1.84.0 Beta 1 Release Candidate 1 is available
by Marshall Clow 17 Nov '23

17 Nov '23

Available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.84.0.beta1/source/> The SHA256 checksums are as follows: f8a9f21580961536a95fb7fcf9deebde45d7e0e94ddd81402f1e37ae2c590410 boost_1_84_0_b1_rc1.tar.bz2 224d595cc666c19b91214c5e9cced3988d08063146dfad9f616c481d52626f27 boost_1_84_0_b1_rc1.zip 3e4765c41974c763b7d4a67a432569bf75d3367d7a6b72c4ac9458e5004c59dc boost_1_84_0_b1_rc1.7z de9b35e232e4b1769f4d800ec01255a9c2546639be43e45b16ce6d109c088e99 boost_1_84_0_b1_rc1.tar.gz As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release Managers

11 28

Do we still want develop branch?
by Andrey Semashev 16 Nov '23

16 Nov '23

Hi, The recent case of a commit in develop that was left unmerged to master made me wondering if people still find the develop branch useful. Historically (since the SVN days), we used a separate branch for active development, which we then merged to the stable branch that was used for creating Boost releases. This allowed to test libraries together before changes propagate to the stable branch. This was useful back when the official test matrix was the primary gauge of the Boost "health", so when something broke, it was rather visible, even if the breakage manifested in downstream libraries. With the adoption of git and CI, the relevance of the test matrix has diminished, and, presumably, people have shifted towards monitoring their libraries' CI. Which means, people are less likely to notice that something broke downstream, unless the downstream developer notices and reports the problem. Although I have been that downstream developer myself quite a few times, I have to admit that this role of the develop branch of "an integration testing field" is not well filled in the current workflow. Noticing the breakage is mostly luck (i.e. a matter of me making a commit to my library and noticing the CI failure caused by an upstream dependency) rather than a rule. Additionally, I have been asked on a few occasions to avoid development directly in the develop branch and use separate feature branches instead. That is, do your commits in a feature branch, let the CI pass, then merge to develop, let the CI pass again, then merge to master. Apparently, some people are using this workflow by default to avoid breakage in develop, which means develop is no longer the branch where the actual development happens. (This workflow actually makes develop meaningless because your CI over the feature branch already tests your changes against develop of the rest of Boost. Which means after merging to develop you're running the same CI again, and might as well just merge to master straight away.) Then there's the recurring problem that led to this post - people forget to merge to master from time to time. Or simply don't have time to merge. Or the library is no longer actively maintained. Or the commit is left out of master for any other reason, which means users don't receive their bug fixes in a release. Personally, I do try to remember the PRs I make during the release cycle and look through them just before the release to make sure they are merged to master. Some of you probably received gentle merge reminders from me. I'm not sure if anyone else is doing this, but I can say this is an active mental effort on my part, which I'd rather not have to make. And even then I can't be sure I remember all PRs or have the time to cycle though them before the release. Which brings me to my question. Do people still find the develop branch useful? Maybe we'd be better off just dropping it and performing all development in feature branches before merging straight to master? Also, if you do find develop useful, what do you think about creating a GitHub Action to automatically merge develop to master once the CI on develop succeeds? Maybe there are other ideas how to avoid commits unmerged to master? Thanks.

8 51

Re: [boost] Do we still want develop branch?
by Jonathan Wakely 13 Nov '23

13 Nov '23

Oops, resending from the address that is actually sub'd the the list ... On Mon, 6 Nov 2023 at 19:13, Jonathan Wakely wrote: > > > On Mon, 6 Nov 2023 at 16:45, Robert Ramey via Boost <boost(a)lists.boost.org> > wrote: > >> On 11/6/23 1:45 AM, Alexander Grund via Boost wrote: >> > I agree here that this is a major issue and maybe the release managers >> > can check (e.g. with Peters script) for that common issue and maybe >> even >> > initiate merges. >> >> Seems to me it would be easy to make a script which the release manager >> would run before release which would flag all libraries which have >> unmerged changes on the development branch dated before the current >> date. This might resolve the whole issue. >> >> > That would imply a rule of thumb that develop should (in general) have no > changes that aren't merged to master ready for a release. > > If you're going to have such a rule, you might as well just get rid of the > two branch model and just use a trunk-based git workflow. So you work on > develop, and then at some point you create a release branch from develop, > call it boost_1_84_0 and that release branch is used for the release. No > manual merging from develop to master, because the release branch comes > straight from develop, not from an unrelated branch which should (in > theory, if the maintainer remembers) match the *content* of develop, but > not the actual history of develop. > > > > https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-… > https://www.toptal.com/software/trunk-based-development-git-flow > https://trunkbaseddevelopment.com/ > >

7 14

[Release] Master branch is closed for beta
by Marshall Clow 09 Nov '23

09 Nov '23

Master is closed for all changes. See the release schedule at: https://www.boost.org/development/index.html -- Release managers

1 0

Re: [boost] [boost.cobalt] A precondition or an error condition?
by Andrzej Krzemienski 09 Nov '23

09 Nov '23

czw., 9 lis 2023 o 17:32 Klemens Morgenstern < klemensdavidmorgenstern(a)gmail.com> napisał(a): > > Actually, your explanation convinces me even stronger that this should > be a different function with a different name. It is a different use case, > it has a different signature, a different return type. > > > > How is the use case different? I got multiple awaitable and I want to > wait for one to finish. The decision of how many is either a runtime > or a compile time decision and we're discussing how to handle the > runtime error. Sounds like the same thing to me. > They have different preconditions: one requires a non-epty variadic pack. One allows promises with different result types, the other doesn't. They differ in return types: one returns a variant, the other returns a pair. So, the following code will look different in either case. Sure they share some similarities. Much like `race` and `left_race` do. But they have two different names. Regards, &rzej;

1 0

[boost.cobalt] A precondition or an error condition?
by Andrzej Krzemienski 09 Nov '23

09 Nov '23

Hi Everyone, I would like to discuss one correctness aspect of Boost.COBALT. We have this list and the Slack channel, so I am not sure which place is better. Let me do it here. In Boost.Cobalt (formerly Boost.Async) we have function cobalt::race (formerly select()) that takes a range of awaitables `p` and returns an awaitable capable on awaiting on one of the elements of `p`: https://www.boost.org/doc/libs/develop/libs/cobalt/doc/html/index.html#race… Example: ``` promise<string> talk_to_server_1(); promise<string> talk_to_server_2(); promise<string> timeout_with_default(); vector<promise<int>> servers = { talk_to_server_1(), talk_to_server_2(), timeout_with_default() }; pair<size_t, string> ans = co_await race(servers); ``` This obviously cannot work when the input range passed to `race` is empty. Boost.COBALT docs say that for this situation "Selecting an empty range will cause an exception to be thrown". But I do not think it is the right approach. The right approach would be to clearly communicate to the user of the library that this is an incorrect usage of the library: if you pass an empty range to `race` you clearly do not know what you are doing, or you simply overlooked it and planted a bug. The library should list it as a *precondition* in the docs: the passed range cannot be empty. If you do it, you cannot expect your program to work correctly. >From the perspective of the library author, you can now, for the event of passing the empty range, putt all the tools that help in debugging: * BOOST_ASSERT * insert a breakpoint And on the next line, you can also throw an exception to avoid an UB. But in that case the exception would not be part of the official contract. If the docs just say "throws an exception" (as today, which I think is wrong) then the library author is not allowed to insert any debugging aids (such as BOOST_ASSERT or breaking into the debugger) because the user may be relying on the exception throw. You do not want the users to rely on the exception throw: you want to prevent the users from passing the empty range. What do others think about it? Regards, &rzej;

3 6

[release] Master branch closes for the 1.84.0 beta release TOMORROW
by Marshall Clow 08 Nov '23

08 Nov '23

Calendar here: https://www.boost.org/development/ — The release managers

3 5

Linking Problems starting with Boost 1.81
by Dennis Luehring 05 Nov '23

05 Nov '23

1.79 links with my software 1.80 links with my software 1.81 does not link 1.82 does not link 1.83 does not link Linux up to date Suse/Tumbleweed gcc 13.2.1 ./bootstrap.sh ./b2 -j16 --toolset=gcc cxxflags=-fPIC --build-dir=./_build address-model=64 architecture=x86 threading=multi --stagedir=./lib64-gcc --build-type=complete --layout=versioned --without-mpi these are the errors on linking when using 1.81 and above ld.lld: error: duplicate symbol: boost::phoenix::placeholders::uarg1 >>> defined at local_256.hpp:16 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:16) >>> Recipe_expression_validator.cpp.o:(boost::phoenix::placeholders::uarg1) in archive ../../implementation/expression_validation/libexpression_validation.a >>> defined at local_256.hpp:16 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:16) >>> parser.cpp.o:(.bss+0xF80) in archive ../../devs/expression_parser_lib/libexpression_parser_lib.a ld.lld: error: duplicate symbol: boost::phoenix::placeholders::uarg2 >>> defined at local_256.hpp:19 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:19) >>> Recipe_expression_validator.cpp.o:(boost::phoenix::placeholders::uarg2) in archive ../../implementation/expression_validation/libexpression_validation.a >>> defined at local_256.hpp:19 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:19) >>> parser.cpp.o:(.bss+0xFC0) in archive ../../devs/expression_parser_lib/libexpression_parser_lib.a ld.lld: error: duplicate symbol: boost::phoenix::placeholders::uarg3 >>> defined at local_256.hpp:22 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:22) >>> Recipe_expression_validator.cpp.o:(boost::phoenix::placeholders::uarg3) in archive ../../implementation/expression_validation/libexpression_validation.a >>> defined at local_256.hpp:22 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:22) >>> parser.cpp.o:(.bss+0x1000) in archive ../../devs/expression_parser_lib/libexpression_parser_lib.a anyone got an idea what changed between 1.80 and 1.81 to let my linking fail with the above errors the expression_parser_lib and expression_validation is my own code

4 8

Reminder: Boost 1.84.0 release cycle starting
by Marshall Clow 04 Nov '23

04 Nov '23

The deadline for “major changes” is next Wednesday, 1-Nov. The beta release will be two weeks later. As always, the release calendar is at: https://www.boost.org/development/index.html — Marshall

5 5

Boost test matrix
by Robert Ramey 04 Nov '23

04 Nov '23

I've merged my develop branch into the the master, waited some time, and reviewed the test results here: https://www.boost.org/development/tests/develop/developer/serialization.html . Given that we intend to release soon, I have a few questions: a) I don't see any windows compilers here. WTF? b) If I switch to "Release View" (upper left hand corner) I expect to see test runs for the master branch. I just get an error message. I can't see how we can think of doing a release with having these issues resolved. Robert Ramey

6 8

error on inclusion of ../boost/math/special_functions/next.hpp
by Robert Ramey 03 Nov '23

03 Nov '23

In reviewing the test matrix: https://www.boost.org/development/tests/develop/developer/serialization.html I'm getting the following error message when on a couple of my tests: > Test output: teeks99-dkr-dc6-17 - serialization - test_complex_text_archive / clang-linux-6.0~c++17 > Rev 1c12b5c15fc82f0cb6d4bd931a057fc050df8a34 / Sun, 29 Oct 2023 21:39:02 +0000 > Compile [2023-10-29 23:34:25 UTC]: fail > > > "clang++-6.0" -fvisibility-inlines-hidden -Wno-c99-extensions -std=c++17 -fPIC -m64 -pthread -O0 -fno-inline -Wall -fvisibility=hidden --target=x86_64-pc-linux -ftemplate-depth-255 -DBOOST_ALL_NO_LIB=1 -DBOOST_ARCHIVE_TEST=text_archive.hpp -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_BEAST_ALLOW_DEPRECATED -DBOOST_BEAST_SEPARATE_COMPILATION -DBOOST_COBALT_USE_STD_PMR=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LIB_DIAGNOSTIC=1 -DBOOST_SERIALIZATION_DYN_LINK=1 -DBOOST_WSERIALIZATION_DYN_LINK=1 -I".." -c -o "/var/boost/run/results/boost/bin.v2/libs/serialization/test/test_complex_text_archive.test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/test_complex.o" "../libs/serialization/test/test_complex.cpp" > > In file included from ../libs/serialization/test/test_complex.cpp:19: > In file included from ../boost/math/special_functions/next.hpp:17: > In file included from ../boost/math/special_functions/trunc.hpp:21: > In file included from ../boost/math/ccmath/ldexp.hpp:15: > In file included from ../boost/math/ccmath/abs.hpp:16: > ../boost/math/ccmath/isnan.hpp:35:29: error: no template named 'is_integral_v' in namespace 'std'; did you mean 'is_integral'? > if constexpr (!std::is_integral_v<T>) > ~~~~~^~~~~~~~~~~~~ > is_integral > /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/type_traits:289:12: note: 'is_integral' declared here > struct is_integral > ^ Looks like a minor snafu in ../boost/math/ccmath/isnan.hpp ... or not. Could someone who understands math/special functions took a look into this? On a totally separate note: I'm getting another failure on the same matrix: Test output: teeks99-dkr-dc6-17 - serialization - test_dll_simple / clang-linux-6.0~c++17 Rev 1c12b5c15fc82f0cb6d4bd931a057fc050df8a34 / Sun, 29 Oct 2023 21:39:02 +0000 Lib [2023-10-29 23:34:28 UTC]: fail See boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden where the links points to a file containing: > Test output: boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden > Rev 1c12b5c15fc82f0cb6d4bd931a057fc050df8a34 / Sun, 29 Oct 2023 21:39:02 +0000 > Compile [2023-10-29 23:34:25 UTC]: succeed > > "clang++-6.0" -fvisibility-inlines-hidden -Wno-c99-extensions -std=c++17 -fPIC -m64 -pthread -O0 -fno-inline -Wall -fvisibility=hidden --target=x86_64-pc-linux -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_BEAST_ALLOW_DEPRECATED -DBOOST_BEAST_SEPARATE_COMPILATION -DBOOST_COBALT_USE_STD_PMR=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -I".." -c -o "/var/boost/run/results/boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/dll_polymorphic_derived2.o" "../libs/serialization/test/dll_polymorphic_derived2.cpp" > > In file included from ../libs/serialization/test/dll_polymorphic_derived2.cpp:13: > In file included from ../libs/serialization/test/polymorphic_derived2.cpp:15: > ../libs/serialization/test/polymorphic_base.hpp:29:13: warning: polymorphic_base imported [-W#pragma-messages] > #pragma message ("polymorphic_base imported") > ^ > In file included from ../libs/serialization/test/dll_polymorphic_derived2.cpp:13: > In file included from ../libs/serialization/test/polymorphic_derived2.cpp:16: > ../libs/serialization/test/polymorphic_derived2.hpp:32:13: warning: polymorphic_derived2 exported [-W#pragma-messages] > #pragma message ("polymorphic_derived2 exported") > ^ > 2 warnings generated. > > Link [2023-10-29 23:34:25 UTC]: succeed > > > "clang++-6.0" -o "/var/boost/run/results/boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/libdll_polymorphic_derived2.so.1.84.0" -Wl,-soname -Wl,"libdll_polymorphic_derived2.so.1.84.0" -shared -Wl,--start-group "/var/boost/run/results/boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/dll_polymorphic_derived2.o" "/var/boost/run/results/boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/libdll_polymorphic_base.so.1.84.0" "/var/boost/run/results/boost/bin.v2/libs/serialization/build/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/libboost_serialization.so.1.84.0" "/var/boost/run/results/boost/bin.v2/libs/filesystem/build/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/libboost_filesystem.so.1.84.0" -Wl,-Bstatic -Wl,-Bdynamic -lrt -Wl,--end-group -fPIC -m64 -pthread -fvisibility=hidden -fvisibility-inlines-hidden --target=x86_64-pc-linux So .... This parts builds a dll/shared library which is used in the test. There doesn't seem to be anything wrong with this. Does anyone have any ideas? Robert Ramey

3 3

Boost Security Disclosure
by Feuer, Mark 02 Nov '23

02 Nov '23

Is there a written security disclosure policy for Boost? As an example, is there a boost document that says all security vulnerabilities will be reported to NIST? If so, can someone point me to the disclosure form? I've seen in some documentation references to CVEs. Does this mean all security vulnerabilities are required to be submitted to NIST? Thanks, Mark [CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this email is proprietary to Medtronic and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please delete this mail from your records. To view this notice in other languages you can either select the following link or manually copy and paste the link into the address bar of a web browser: http://emaildisclaimer.medtronic.com

1 0

[release] Master Branch is closed for major code changes
by Marshall Clow 02 Nov '23

02 Nov '23

The master branch closed for major code changes. Still open for serious problem fixes and docs changes without release manager review. The master branch will close for the 1.84.0 beta release next Wednesday As always, the calendar is available at: https://www.boost.org/development/ — The release managers

1 0