January 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

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.Buffers: network-agnostic buffer types and algorithms
by Vinnie Falco 07 Feb '23

07 Feb '23

Greetings. I am asking if there is any interest in a Boost.Buffers library, which consists of the following: * ConstBuffer, MutableBuffer concepts * ConstBuffers, MutableBuffers concepts * const_buffer, mutable_buffer types * DynamicBuffer concept * `source` and `sink` abstract interfaces used to define the Source and Sink concepts * metafunctions for checking all type requirements * implementations of common buffers and dynamic buffers: - buffers_pair - array_of_buffers - circular_buffer - dynamic_string_buffer * Algorithms: - buffer_copy - buffer_size The twist is that this library has no dependency on Asio or Boost.Asio (but Asio will still recognize them thanks to some template heroics and a splash of forward declarations). Why am I proposing this? Well, let me tell you some things... I am currently working on these two libraries: Boost.Http.Proto Boost.Http.Io The Proto library implements HTTP/1 to a fuller feature set than Beast and fixes all the design flaws in Beast (but it is completely not API compatible). This library does not do any network I/O, it is expressed purely in terms of buffer concepts (i.e. depends on Boost.Buffer and not Boost.Asio). The Io library depends on Asio and the Proto library to provide the network algorithms which use Asio to implement HTTP/1. This is the equivalent HTTP functionality of what Beast offers today. Websockets is not included but when I am done with Http I will redo websockets with improvements and new features, and similarly they will be developed as two libraries: Boost.Websockets.Proto Boost.Websockets.Io My motivation for splitting libraries this way is as follows: * Each library is smaller and compiles more quickly * CI turnarounds are faster * Separation of concerns The HTTP Protocol library is designed in a way that much of an application's HTTP business logic can be expressed independently of Asio using only the constructs found in Http.Proto. This especially means fewer templates and faster compilation because Http.Proto is designed from the ground up to avoid templates whenever possible. However during the development of Http.Proto I find myself having to reach for the same buffer algorithms and containers that I developed for Beast (such as the circular buffer and the dynamic buffer). So Http.Proto has been steadily growing these things: <https://github.com/CPPAlliance/http_proto/blob/a3a284f06597ad12ca6cc1782beb…> Extract this independent buffer functionality into a separate library Boost.Buffers would bring these benefits: * Again a smaller library, faster compilation * Faster CI turnarounds * Separation of concerns Additionally, algorithms can be expressed in terms of asio-independent buffer types and concepts. For example, Boost.JSON could implement the boost::buffers::sink and boost::buffers::source interfaces which would enable its use in Boost.Http.Proto and Boost.Requests (an upcoming HTTP client library from Klemens), without having to depend on either of those libraries or Asio. Is this style of development of smaller, fine grained libraries that separate concerns something that is desirable for Boost? Glad for any feedback. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

11 29

Decommissioning Trac (svn.boost.org)
by Glen Fernandes 31 Jan '23

31 Jan '23

We have Trac in read-only mode after we migrated to Git, but we're still paying for the server. Do people still want to preserve any part of the content in some way? The wiki aside, there are old issues, with comments, and some of them have patches attached. Peter had the idea of generating static HTML content from Trac and hosting that on an archive section on boost.org. (I don't know how difficult this is to do). Thoughts? Suggestions? Glen

5 7

Boost TCP socket read/write issues
by Rahul K R 31 Jan '23

31 Jan '23

Hello All, As part of my project activity, I have to create an asynchronous TCP server application using the boost library. I have created a sample application and it's working. But the issue I am facing is the boost::asio::read API takes a long time to read from the TCP socket, almost 5 seconds. I am using boost library version 1.76.0. I have the following queries regarding this, 1. Is there any known issues for boost::asio::read to consume more time? 2. I am doing reading and writing to the same socket from two threads parallelly, Is that possible with the boost? 3. Is the boost lib can perform well if we get too many requests at a time and process parallelly? I am attaching the sample application code herewith. Please let me know your feedback asap. Regards Rahul

2 1

GSoC 2023 (Google Summer of Code)
by David Bellot 31 Jan '23

31 Jan '23

Hi Boost community, the GSoC 2023 organisation application is now open. Boost is again a candidate this year. We're just waiting for the results to see if we're accepted. In the meantime, we are "recruiting" mentors. Some of you already contacted me a few weeks ago, but maybe some others would be interested to join this fascinating journey. Please contact me now, by mailing list or private email if you're interested. Best, David

2 1

Building the proposed Boost.Mustache
by Peter Dimov 30 Jan '23

30 Jan '23

It's been pointed out that the proposed Boost.Mustache https://github.com/pdimov/mustache (whose formal review is upcoming) is relatively hard to evaluate, because the contents of the repository are in a form that is intended for inclusion into a Boost release. Here's how to build the library, starting from scratch: 1. Clone Boost from Github: git clone --recurse-submodules https://github.com/boostorg/boost 2. Clone the Mustache library into the Boost tree: cd boost/libs git clone https://github.com/pdimov/mustache cd .. 3. Build b2: ./bootstrap.sh (We assume Linux and g++ from now on. On Windows, it's just `booststrap`.) 4. Generate the header links in the boost/ directory: ./b2 headers 5. Build the Mustache library and its dependencies (e.g. JSON): ./b2 --with-mustache This will place the compiled libraries into the stage/lib directory. It should contain libboost_container.a/.so, libboost_json.a/.so, and liboost_mustache.a/.so. You can now build and run the Mustache examples by using e.g. g++ libs/mustache/example/html.cpp -o html -I . -L stage/lib -lboost_mustache -lboost_json ./html

1 1

aedis is ACCEPTED into boost with conditions
by Klemens Morgenstern 28 Jan '23

28 Jan '23

Boost.aedis is ACCEPTED with conditions. Accept: 3 ( + 1 late one) Conditional: 1 Reject: 4 All but one rejections asked for changes that were not fundamental to the design, but rather were about particular implementation details or high-level API design issues. Thus I conclude, based on the reviews, that there is no need for another mini-review. This is also based on Marcelo's engagement, so I am confident that many issues will be addressed in the future . These are the conditions - name it boost.redis - clearly document/specify the behaviour of async_exec, async_receive & async_run, how they interact and all the edge cases (and unit test them) - unit tests for error handling, especially for pipes. - add a design discussion & FAQ page. That should mostly copy & paste from the review discussions. - from_bulk & to_bulk should either us tag_invoke or be be renamed to aedis_from_bulk or aedis_to_bulk - remove memory_resource usage and optimize the allocation strategy of a request object (using new/delete), so that it ideally allocates once and then reuses the memory Please note that the inclusion into boost does not mean that it has to be shipped with the next release. I also strongly recommend development of typed commands, possibly with code generation. This is however not a condition and does not need to be in the first release that's included in boost. Another recommendation is to add some very basic explanation of redis, as some users will read your doc before they look into redis. I want to thank everyone who submitted reviews, especially Ruben who really drilled down on some details and brought in his experience from MySQL. Thank you Zach for getting the discussion started on type-safe command access; based on the discussions I am confident that some feature like that will be added on top of the existing APIs. Similarly I want to thank Дмитрий, Sam & Alan, who's review helped me to formulate the conditions. I am also grateful for (who I think are) first time reviewers, Mohammed Nejati, Robert Leahy, Sam Hartsfield & Miguel, and of course our boost veterans Vinnie & Christian. Likewise I want to thank Marcelo for all his responses to reviews and questions and of course for all the work that went into developing aedis. Congratulations Marcelo!

5 6