September 2023 - Boost - lists.stage.boost.cppalliance.org

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 199

Boost Governance?
by René Ferdinand Rivera Morell 09 Aug '24

09 Aug '24

A disclaimer: I write this solely as a Boost Library author. And not in any other capacity or representing any other interest. It's now been at least a year since Boost switched from the Software Freedom Conservancy to the Boost Foundation for its governance organization. But have people noticed any difference? Did you know that switch happened? Did you know that they held an election for the Board of Directors and for the Officers? Do you know when that election happened? Do you know who got elected? Do you know how they were selected? Do you know what their responsibilities are? Do you know what their bylaws are? Do you know their financials? More importantly: Did you answer "no" to any of those questions? As a library author, I can say I definitely answered no to many of those questions. This is a problem. As authors, without asking, we should know those answers from the organization that governs our work. We should have input into how that organization governs. In other words, we deserve open and transparent governance; not the closed and opaque status quo. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

10 9

Paul Bristow
by John Maddock 08 Aug '24

08 Aug '24

I've just heard that Paul Bristow who helped so much with the development of Boost.Math and indeed many other libraries, passed away peacefully last week. RIP Paul. Much missed. John.

6 5

boost::any_cast gives build errors with VS2022, boost v1.82 and C++17
by Bhuyan, Jyotideep 01 Jul '24

01 Jul '24

Hi, I was using VS2019, boost v1.78, and C++14 version and the below code was working well. Same code gives build error with VS2022, boost v1.82, and C++17 due to "o << *boost::any_cast<T>(&a); " Instruction. I wanted to know why it behaves differently. Code : class any_out { struct streamer { virtual void print(std::ostream& o, const boost::any& a) = 0; virtual streamer* clone() = 0; virtual ~streamer() {} }; public: any_out() : m_streamer(nullptr) { } ~any_out() { delete m_streamer; } template <typename T> any_out(const T& value) : m_streamer(new streamer_imp<T>), m_object(value) { } any_out(const any_out& a) : m_streamer(a.m_streamer ? a.m_streamer->clone() : nullptr), m_object(a.m_object) { } template <typename T> any_out& operator=(const T& r) { any_out(r).swap(*this); return *this; } any_out& operator=(const any_out& r) { any_out(r).swap(*this); return *this; } any_out& swap(any_out& r) noexcept { std::swap(m_streamer, r.m_streamer); std::swap(m_object, r.m_object); return *this; } friend std::ostream& operator<<(std::ostream& o, const any_out& a) { if(a.m_streamer) { a.m_streamer->print(o, a.m_object); } return o; } boost::any& get() { return m_object; } const boost::any get()const { return m_object; } bool empty() const { return m_object.empty(); } private: template <typename T> struct streamer_imp : public streamer { virtual void print(std::ostream& o, const boost::any& a) { try { if (a.empty()) { o << "<empty>"; } else { o << *boost::any_cast<T>(&a); } } } virtual streamer* clone() { return new streamer_imp<T>(); } }; // Members streamer* m_streamer; boost::any m_object; }; I have migrated to VS2022, boost v1.82, and C++17, and due to a build error, I have changed the code below. virtual void print(std::ostream& o, const boost::any& a) { try { if (a.empty()) { o << "<empty>"; } else { o << boost::any_cast<T*>(a); } } } any_out anyTest; anyTest = 100; std::string actualStr; actualStr = make_string() << anyTest; actualStr prints nullptr (0000000) instated of value 100 for VS2022, boost v1.82 and C++17 Best Regards, Jyotideep (JD) Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment. Confidential - Company Proprietary

3 3

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

[scope] Looking for endorsements and review manager
by Andrey Semashev 31 Oct '23

31 Oct '23

Hi, This is a reminder that Boost.Scope is looking for endorsements and a review manager. Following is an excerpt from the previous announcement, describing the library. 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. Compared to <experimental/scope>, some notable extensions are: * A new scope_final scope guard, which is a more lightweight alternative to scope_exit. It is accompanied with the BOOST_SCOPE_FINAL macro that allows to simplify scope guard declaration syntax. * Scope guards can be activated/deactivated multiple times. * Scope guards can be created inactive initially. * Scope guard factory functions, for compatibility with C++11. * Support for optional resource traits in unique_resource wrapper, which improves usage with resources having unallocated values. * unique_resource supports swapping. * unique_resource supports dereferencing for any resource types that support dereferencing, not only pointers. * More flexible constructors for unique_resource. The library requires C++11 at the minimum and will significantly benefit from C++17. Source: https://github.com/Lastique/scope Docs: https://lastique.github.io/scope/libs/scope/doc/html/index.html The library is tested in CI and used in production in one of my projects. Thanks.

5 14

Library proposal - indexed_array
by Julien Blanc 12 Oct '23

12 Oct '23

Hi, I've written and released a (rather small) library which allows defining arrays with arbitrary index mechanisms (hence the name, indexed_array). This especially allows indexing with scoped enums, use non zero-starting indexes, or use sparse indexes. This is not a view, but an array in the sense that it owns the data, and provides the same guarantees and functionalities as std::array, such as triviality propagation, being able to reside in read-only program sections, etc. It also supports multidimensional indexing, and provides an indexed_span template class to access lower dimension content (which can be used outside indexed_array). Finally, it provides an opt-in safer way to initialize the array content, which is especially useful when using complex and/or changing indexing schemes (like based on externally generated files). The library is available here: https://github.com/Julien-Blanc-tgcm/indexed_array And the doc is here: https://julien-blanc-tgcm.github.io/indexed_array/ It requires C++17 and mp11, and has first-class support for describe-d enums. If there is some interest, i'd like to propose it for inclusion in boost. So i'm looking for people who would endorse it. Thanks and best regards, Julien

8 24

Windows Regression Runners - Failing on Develop
by Tom Kent 02 Oct '23

02 Oct '23

Starting sometime between 3am and 5pm on September 11, 2023, all the windows regression runners started failing on the develop branch. Master branch runners on the same VM are still doing fine ( https://www.boost.org/development/tests/master/developer/summary.html) The output doesn't have anything jump out at me. Nor were there any commits to the develop branch in that window that seem suspicious to me. The regression run output ends with: ...found 1 target... # Searching for "process_jam_log.exe" in "C:\teeks99-09\run\boost_regression\stage\bin"... Traceback (most recent call last): File "run.py", line 71, in <module> runner(root) File "C:\teeks99-09\run\boost_regression_src\regression.py", line 286, in __init__ self.main() File "C:\teeks99-09\run\boost_regression_src\regression.py", line 623, in main getattr(self,action_m)() File "C:\teeks99-09\run\boost_regression_src\regression.py", line 580, in command_regression self.command_setup() File "C:\teeks99-09\run\boost_regression_src\regression.py", line 351, in command_setup self.build_if_needed(self.process_jam_log,self.pjl_toolset) File "C:\teeks99-09\run\boost_regression_src\regression.py", line 714, in build_if_needed tool[ 'build_path' ] = self.tool_path( tool ) File "C:\teeks99-09\run\boost_regression_src\regression.py", line 739, in tool_path , '\n'.join( [ name_or_spec[ 'path' ], build_dir ] ) Exception: Cannot find "process_jam_log.exe" in any of the following locations: C:\teeks99-09\run\boost_regression\stage\bin\process_jam_log.exe C:\teeks99-09\run\boost_regression\stage\bin With the full output available here: https://gist.github.com/teeks99/bb4230f6a1efdd7af11bd93341c950bf Any ideas on this would be much appreciated.

5 15

[boost.async] Andrzej's review
by Andrzej Krzemienski 01 Oct '23

01 Oct '23

Hi Everyone, I would like to thank Klemens for writing and sharing the Async library. It is something the community needs, and it is clear that a lot of thought and effort was put in it. I am not an expert on C++ coroutines or coroutines in general. I have played with a few echo-server examples in the past from Boost.ASIO, and created some toy examples of C++ coroutines. I devoted something like twelve evenings studying the Boost.Async: reading docs, testing toy examples (Windows 11, MSVC 2022), debugging and asking Klemens a lot of questions. Still, I cannot say I understand the library well enough to be able to responsibly give a recommendation. But I can still share my observations. On the design. Although my knowledge is superficial, I will risk a claim that the synchronization mechanisms and supporting features (`with`, channels, work_group) are the strong part of the design. (I disagree with the overload set for `select`, but I guess this is a non-design bug.) Regarding the choice and design of "coroutine types", I have certain reservations. It is still not clear to me why we have two -- promise and task -- and when I should use which. The docs give some answer: promise is eager, task can be awaited/spawned on another executor than it was created on. But is that it? I sense that there is a good reason to have them as two types, a better/clearer one than this described in the docs.But I fail to see it, and the docs do not explain it clearly enough, I think. I am uneasy about the design for `generator`. I filed a couple of issues: https://github.com/klemens-morgenstern/async/issues/101 https://github.com/klemens-morgenstern/async/issues/70 One problem is how the `generator` signals that it has finished. In all the examples it has to create a dummy value. I hear from Klemens that it is a necessity imposed by the coroutine design in C++. I do not feel competent to confirm it or not. But I note that std::generator does not require the user to `co_return` anything. And that asio::experimental::coro does allow the user to specify that they do not want to co_return even if they co_yield things. Regarding the value-returning generators, I have even more reservations. As noted in one of the quoted GitHub issues, the fact that it has a different interface than the normal generator, and that it has to be lazy to be usable, It looks to me like it qualifies for a separate coroutine type. On the documentation. The only other library offering coroutine support and any documentation that I know of is Boost.ASIO. In comparison to Boost.ASIO, Boost.Async has a waaay better documentation. It is big (in a positive sense), it has a lot of tutorial materials, lots of ideas explained, it is still being improved. It is waaay above the average quality of a library documentation that you can find on the web. But still I would greatly appreciate an even better one, however arrogant that seems. My reasoning is that for the next couple of years people who will consider Boost.Async will not only be unfamiliar with the library but also with C++ coroutines in general. They will need additional extra help to be able to use the library responsibly. To be more specific, I would expect more full compiling examples (those in folder examples) that illustrate different aspects of the library. For instance: * A convincing example of value-returning generator * timeout implemented in terms of `async::select`. I would expect a more detailed explanation of concepts used in this library: * interruption and cancellation, and how they differ, and when/if I should care about them. * being detaching and being detached, and how it is different from spawning. I got a response in one of GitHub issues that, "Interrupt is [...] meant to make select work lossless. What gets detached is the co_await itself, not the awaited thing." I feel the documentation should explain it more cleanly, and perhaps introduce some more well defined terms. The library does not cleanly communicate preconditions on the operations. I think it sometimes decides to throw an exception when a precondition is more appropriate. In other places it is silent about the corner cases. It also does not specify clearly what is guaranteed of the provided operations. Klemens correctly points out that postconditions are tricky in the case of asynchronous operations, but (1) some things in the library are not asynchronous and (2) this library (like any other) does offer some guarantees, if not on individual function calls, then for the entire expressions. For instance `co_await select(aw1, aw2)` does provide a guarantee that the result of one of the awaitables will be returned and the others will be interrupted. It should be specified in the synopsis of `select`. On the implementation. It is mostly magic to me, so I do not have much to say. There are a lot of awaitable types created whose existence I could not predict from studying the docs. I cannot say if this is a deficiency of the documentation, or is this how the C++ coroutines work: you might need a lot of awaitables that are implementation details. I find the design of the overload set of functions `select` bad and generic-programming-unfriendly. I explained it in detail in: https://github.com/klemens-morgenstern/async/issues/103 Functions that do slightly different things should have different names. Returning different types for special cases breaks generic code, and causes surprises, sometimes runtime surprises. Also, because the overload for value-returning promises returns a variant, I have run into an interesting situation when trying to add a timeout support to the echo server example. I get the following statement: ``` variant2::variant<variant2::monostate, tcp_socket> ans = co_await async::select( timer.async_wait(async::use_op), acceptor.async_accept() ); ``` And now I have a variant to unpack inside a coroutine. Normally, the recommended way to unpack a variant is to use a visitor: ``` struct visitor { void operator()(tcp_socket&& sock) { co_yield std::move(sock); // ERROR } void operator()(variant2::monostate&&) { } }; visit(visitor{}, std::move(ans)); ``` But this doesn't work, because now I am co_yield-ing from a non-coroutine. And I have to resort to manually inspecting the variant, which is taught to be error prone. I guess this is the right choice to use variant for the return type of `select`, and that it is the limitation of variant, until C++ gets pattern matching. But still, it would be helpful if the documentation (or examples) illustrated what potential difficulties the user can expect. Should the library be accepted to Boost? Again, I am not competent enough in the domain of coroutines, to responsibly say that the library meets the bar, but because I think the community desperately needs this kind of library with Boost-quality docs and support, I will risk saying that Boost.async should be conditionally accepted. The conditions being: * Address the design of generators (either change it or provide a clearer rationale) * Improve the docs - clearly describe the notions of interrupting, canceling, detaching, spawning. - provide a more detailed synopses for functions and classes with preconditions, described effects, and the guarantees. I filed this as a list of issues in the GitHub: https://github.com/klemens-morgenstern/async/issues/120 https://github.com/klemens-morgenstern/async/issues/119 https://github.com/klemens-morgenstern/async/issues/117 https://github.com/klemens-morgenstern/async/issues/115 https://github.com/klemens-morgenstern/async/issues/114 https://github.com/klemens-morgenstern/async/issues/103 https://github.com/klemens-morgenstern/async/issues/101 https://github.com/klemens-morgenstern/async/issues/100 https://github.com/klemens-morgenstern/async/issues/70 https://github.com/klemens-morgenstern/async/issues/64 Finally, while the above might look like a list of complaints, I really appreciate the work that was done in order to provide this library, and the solutions that were applied (like the clever use of await_transform). I learned a lot from studying this library, and my intuition tells me that it will end up being a great addition to Boost. I also appreciate the responsiveness of the author. Klemens has been answering a lot of my questions in a timely fashion, and improving the docs based on feedback. Thanks! Regards, &rzej;

2 2

[Async] Second attempt at review of proposed Boost.Async begins
by Niall Douglas 01 Oct '23

01 Oct '23

Dear Boost, Due to too few reviews last time, we are going to try again the review of this library. This review shall run between Friday 22nd September and Monday 2nd October. Please do consider contributing a review! My thanks to Marcelo Zimbres Silva for the only formal review last time, and to the others including those on Reddit /r/cpp and by private email who submitted feedback. All your reviews and feedback have been retained and will be reused for this review. To remind you all, Boost.Async is a C++ coroutine programming library based around Boost.ASIO as the executor, with a unique set of properties which make it incomparable to most existing C++ coroutine programming libraries. To be specific, it lets you compose arbitrary third party awaitables without any additional effort, which lets you tie together third party libraries with ease and convenience. Changes to proposed Boost.Async since the last review: 1. Major doc improvements & bug fixes 2. PMR is optional 3. optimized associated allocator for use_op 4. lazy generator support 5. public unique_handle & more examples with custom awaitables 6. as_result/as_tuple support (akin to the asio stuff, but takes an awaitables, i.e. co_await as_result(foo())) - reduces unnecessary exceptions. 7. with supports return values. You can read the documentation at https://klemens.dev/async/ and study or try out the code at https://github.com/klemens-morgenstern/async. Anyone with experience using C++ coroutines is welcome to contribute a review at the Boost mailing list (https://lists.boost.org/mailman/listinfo.cgi/boost) at /r/cpp on Reddit, via email to me personally, or any other mechanism where I the review manager will see it. In your review please state at the end whether you recommend acceptance, acceptance with conditions, or rejection. Please state your experience with C++ coroutines and ASIO in your review, and how many hours you spent on the review. Thanks in advance for your time and reviews! Niall

4 4