August 2023 - Boost - lists.preview.boost.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

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

[boost.async] Some feedback
by Andrzej Krzemienski 29 Aug '23

29 Aug '23

Hi Everyone, I will not be able to write a decent review due to the lack of time (I am now on vacation), but I wanted to share some partial feedback. I am not well familiar with C++ coroutines. I wrote some toy examples of an async TCP echo server in ASIO in the past, to try to learn how coroutines work, but my knowledge is very superficial. I hoped to understand coroutines better from studying Boost.Async's docs. When I discovered Boost some 18 years ago, I found it useful not only because of the high quality libraries but also because of extraordinary documentation that often provided a very deep insight into the problem domain, a lot of rationale, design goals, and the documentation of engineering trade-offs of different sorts. I do not know how people feel about the importance of documentation nowadays. For me, however, it is the primary focus. I devoted like 10 hours in total for studying the docs and running some toy examples. Because I am not very good at C++ coroutines, you get a typical, I would think, feedback from a user that wants to learn how coroutines are used, what problems they solve, and what problems they do not solve. Regarding the *really* asynchronous part, promises and tasks, I guess they would work fine. By "really asynchronous" I mean the situations where a coroutine is resumed by events unpredictable by the programmer (when data arrives, when certain time passes, when an external connection is requested). I also guess that when Marcelo and Ruben say they successfully integrated Boost.Async into their projects, they meant types `task` and `promise`, rather than `generator`. My investigation was interrupted by `generator` which I cannot understand or appreciate. It feels like a type quite separate from the rest of the library. For instance, through all the simple examples in the docs, only the examples for `generator` never use the trick with `co_await async::this_coro::executor`. I needed to ask a lot of questions, and even though Klemens is very responsive and very helpful, I still do not understand how `async::generator` solves real problems. This may indicate that either I am a very slow learner, or that there is something wrong with the design of `generator`. But even if it is the former, I think I represent the average user of this library. When I try to use a C+23 std::generator, the usage is intuitive and straightforward to me. I know how to easily yield a sequence of values, and on the caller side how to easily check if I can still obtain the next value from the generator: ``` std::generator<int> seq(int from, int to) { for (int i = from; i <= to; ++i) co_yield i; } int main() { for(int i : seq(1, 4)) std::cout << i << std::endl; } ``` https://godbolt.org/z/PTvz3v4Y6 But when I try what I believe to be an analogous example in Boost.Async, I get an exception: ``` async::generator<int> seq(int from, int to) { for (int i = from; i <= to; ++i) co_yield i; } async::main co_main(int argc, char* argv[]) { auto s = seq(1, 4); while (s) { std::cout << co_await s << std::endl; } } ``` And the docs or examples don't help me understand why this use case doesn't work. The case with the eager generator that can be injected values is even weirder. I think it is wrong. Klemens thinks otherwise, but the docs do not give any convincing example of where and how it could be used. The lack of examples or description can be just that, but it could also indicate that the design for generators is missing something. In this feedback, I am only mentioning generators, because this is the place where I stuck in my review. I guess that other parts of the library do not have this problem. I am pretty sure that this library will be accepted into Boost at some point. It addresses a real need (although not necessarily the generators), and the feedback from Ruben and Marcelo are strong testimony to the quality of the library. But at this point, I am not comfortable with adding a library whose design for generators cannot be explained in the docs to the extent that I consider satisfactory. Would this library lose in usability if generators were removed? I know it is not a fair review. I only covered one subject, and my feeling is that it is not the most relevant one. So please consider it as "just feedback" rather than a review. Again, thanks Klemens for writing and sharing this library. I hope that this message does not come across as negative. I want to think that I am contributing to the quality of Boost.Async. Regards, &rzej;

2 2

remez, chebyshev polynomial approximation
by Brian Budge 25 Aug '23

25 Aug '23

Hi folks - I have a couple of questions regarding the math tools for polynomial approximation. Context: I'm interested in making fast math approximations that are also highly accurate. These include standard functions, but also custom fits. I've successfully used the chebyshev_transform and remez tools to make such approximations. However, I know in many cases I could get better results. So my questions are the following: 1. For the remez tool, how could we constrain e.g. odd or even powers of numerator, denominator, or both to zero? This is common in highly accurate trig approximations for example. Looking at the code, I suspect we'd need to change the degrees of freedom for the solver, but I don't know how straightforward it would be to make such a change (or if there are theoretical reasons why this couldn't work with the remez algorithm) 2. Getting accurate results with chebyshev_transform requires the Crenshaw algorithm, which makes these approximations far slower than those I get from the remez tool. Are there a class of polynomials where I could transform these to a standard Horner's or Estrin's scheme in a way that is numerically stable? If so, any pointers to how to do that? Thanks, Brian

2 3

[Async] Try again review
by Niall Douglas 23 Aug '23

23 Aug '23

I received one formal review, and two bits of substantial feedback. My thanks to their authors. I received more formal requests to run the review in September than reviews, so I guess we're going to have to try this review again. Does anybody object to Friday 15th September to Monday 25th of September? Niall

5 11

[boost.async] Some questions
by Andrzej Krzemienski 20 Aug '23

20 Aug '23

Hi Everyone, I would like to thank Klemens for writing and sharing this library. I am sure the community needs a higher level library for asynchronous computations based on C++20 coroutines. Boost.Async addresses the need. I would like to ask a couple of questions to better understand the design goals and the scope of the library. Q1. Is single-threaded-ness the design goal? Or is the plan to enable multi-threaded use cases? There is a GitHub issue ( https://github.com/klemens-morgenstern/async/issues/19) suggesting the latter. Q2. Reading through the docs, I get an impression that Boost.Async is "Either a wrapper over ASIO, or an isolated usage for a generator". They seem like two unrelated worlds. The former requires a hard prerequisite of having a Boost.ASIO library (with Boost version at least 1.82). The latter can hardly be called "asynchronous". Generators, the way I understand them, are perfectly synchronous. Is this impression correct? The following are more remarks regarding the choice of names. Q3. The docs say that `promise` and `task` differ primarily by their level of eagerness. But the names do not seem to reflect this. What is the rationale or the intuition behind those names? R1. I find the name `use_op` uninformative. The examples in documentation suggest that it is an *adapter*: they change the Boost.ASIO interface into the Boost.Async interface. Is that correct? Regards, &rzej;

3 11

[boost.asynch] another generator query
by Andrzej Krzemienski 19 Aug '23

19 Aug '23

Hi Klemens, I have another question regarding the generator. I think the initial examples in the dcs for `generator` are too simplistic, because the caller seems to already know how many times it is allowed to co_await on the Awaitable. I tried it with a loop, where I use the explicit conversion to bool to check when to break the iteration: ``` async::generator<std::string> worker(int limit) { for (int i = 0; i < limit; ++i) { co_yield std::format("--{}--", i); } } async::main co_main(int argc, char* argv[]) { try { auto w = worker(3); while (w) { std::cout << co_await w << std::endl; } } catch (std::exception const& e) { std::cout << "ERR: " << e.what() << std::endl; } } ``` But I am surprised that this construct ends with throwing an exception. Am I doing something wrong? Regards, &rzej;

2 2

[Async] Review of proposed Boost.Async begins
by Niall Douglas 18 Aug '23

18 Aug '23

Dear Boost, It is my great pleasure to announce the beginning of the peer review of proposed Boost.Async, which is hoped to become the most popular way of programming C++ coroutines in future C++. The peer review shall run between Tuesday 8th August and Friday 18th August. Like many of you have found, until now there has been no good standard and easy way of writing C++ coroutine code which works easily with multiple third party codebases and foreign asynchronous design patterns. ASIO’s current coroutine support is tightly coupled to ASIO, and it rejects foreign awaitables. Libunifex is dense to master and non-obvious to make work well with foreign asynchronous design patterns, not helped by a lack of documentation, a problem which also afflicts stdexec which also has a steep and dense learning curve. CppCoro is probably currently the best in class solution to the space of easy to use fire and forget C++ coroutine programming, but it isn’t particularly portable and was designed long before C++ coroutine standardisation was completed. Klemens very kindly stepped up and created for us an open source ground-up reimplementation of the best ideas of hitherto proprietary commercial C++ coroutine libraries, taking in experience and feedback from multiple domain experts in the area to create an easy to use C++ coroutine support library with excellent support for foreign asynchronous design patterns. For example, if you want your coroutine to suspend while a stackful fiber runs and then resume when that fiber has done something – AND that fiber implementation is unknown to Boost.Async – this is made as easy as possible. If your C++ coroutine code wants to await on unknown foreign awaitables, that generally “just works” with no added effort. This makes tying together multiple third party dependencies into a solution based on C++ coroutines much easier than until now. The industry standard executor is ASIO, so Boost.Async uses Boost.ASIO as its base executor. To keep things simple and high performance, Boost.Async requires each pool of things it works with to execute on a single kernel thread at a time – though there can be a pool of things per kernel thread, or an ASIO strand can ensure execution never occurs on multiple kernel threads. The basic concurrency primitives of promise, generator and task are provided, with the fundamental operations of select, join and gather. Some more complex async support is supplied: Go-type channels, and async teardown. Performance is superior to both stackful coroutines and ASIO’s own C++ coroutine support, and sometimes far superior. 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) here at this Reddit page, 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

8 13