- Boost - lists.boost.org

Question regarding Boost Documentation
by Robert Ramey 11 Aug '24

11 Aug '24

I think I recall that from time to time I see reference to a "global" (my term) documentation build which builds an html tree of all the boost libraries whose documentation has been built with boostbook. But in perusing the website I don't find any such documentation. What am I missing here? Robert Ramey

9 26

[circular_buffer] Is it usable in embedded contexts?
by Andrzej Krzemienski 11 Aug '24

11 Aug '24

Hi Everyone, This is a couple of questions about Boost.Circular_buffer, but also about Boost in general. A colleague of mine says he needs a ring buffer for usage in the embedded context, and I am investigating why he chooses to write his own rather than using Boost.Circular_Buffer, even though he knows the latter exists. It is a natural expectation for containers like static_vector/inplace_vector, array, circular_buffer to be a natural fit for the embedded contexts, as, at least in principle, they should not require any memory allocation. Question 1: Is Boost a suitable place for libraries targeting systems where exceptions, RTTI and memory allocation are banned? I tried to check what Boost.Circular_Buffer offers, and I was surprised that it requires at least one, initial allocation. Maybe I could get away with a custom allocator, but then why do we have static_vector, rather than the advice to use std::vector with "in-place allocator"? Question 2: Is it a reasonable expectation of a ring buffer to not require allocations? I tried to find more details in the docs, but I found that the entire reference documentation for class template circular_buffer is missing from the docs. Question 3: Is Boost.Circular_Buffer actively maintained? The last commit is from three years ago. One thing, my colleague says, that puts him off from even considering Boost.Circular_Buffer is the amount of headers that circular_buffer.hpp directly and indirectly includes. This dwarfs the number of headers in his entire project. Also the fact that Boost.Circular_Buffer includes the standard headers is problematic, as some standard-mandated headers are not available on some embedded platforms. A lot of these dependencies are for emulating C++11 features, like static_assert, which may not be necessary if we assume some C++11 level of compiler conformance. Question 4: Maybe there would be a value, at least for some Boost libraries, to provide a single-header, header-only variant that works under some assumptions, like C++11 compiler? My colleagues use case is that, because removals from the buffer can occur asynchronously, when doing a pop_back() there is no way to be sure that the buffer is non-empty, so this would require a function that does the check and the pop_back at one go. I am interested to learn what others think about this. Ideally, I would like for Boost to be in a state where developers prefer to use it rather than writing their own popular components. Regards, &rzej;

4 3

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 10

New Logo Discussion
by Vinnie Falco 09 Aug '24

09 Aug '24

Hi. It is CppCon 2024 season, and the C++ Alliance is working on letting people know all the new and exciting things happening in Boost. We're doing this with Boost labeled conference shirts, and a beautiful brochure. You can see a draft of this promotional piece here (note: work in progress): https://cppalliance.org/pdf/Boost-Brochure-CppCon-2024.pdf The new Boost logo was developed by the Alliance, and a community consensus is needed if we are to fully move forward with its use. I am hoping this will spark the necessary discussion. Here are things to consider: * The logo is professionally designed by https://grainandmortar.com/ at a cost of $12,000 * Peter Dimov likes the image (this should not be construed as his endorsement or opposition to any of the above). * The image is a trademark of The C++ Alliance: https://tsdr.uspto.gov/#caseNumber=98417319&caseSearchType=US_APPLICATION&c… * Usage of the logo is governed by our Logo Usage Policy, a product of legal review at a cost of $4,000: https://www.boost.io/doc/contributor-guide/docs/logo-policy-media-guide.html * The Logo Usage Policy allows free usage without permission in Boost-related contexts. Otherwise, explicit written permission from the Alliance is required. * Trademark ownership by a registered entity with sufficient resources is necessary to protect the mark, which David Sankel alludes to here: https://lists.boost.org/Archives/boost//2024/03/256092.php * Adopting this logo costs Boost nothing. If our proposed arrangement stops working for the community, the libraries can easily adopt a different logo (including the old one, or none). Put simply, I am asking the Boost community to entrust The C++ Alliance.with the responsibility of establishing and maintaining this new Boost logo. Thanks :)

18 63

Alumni Program
by Vinnie Falco 09 Aug '24

09 Aug '24

All: I've been engaged more with long-time members of the Boost community, and something which I now realize is the extraordinary level of camaraderie and brotherhood which sprang from the early years of Boost evolution. Boost was a family and like all families, it has changed. People left, new people joined, priorities shifted, and such. Contribution to the libraries is something special, so I would like to introduce an idea. The "Boost Alumni Program." Like a college alumni program this is designed to help Boost contributors stay in touch over the years. There could be a mailing list, and a program administrator who is tasked to keep track of everyone, including their email and phone number. They can keep contact and track changes in careers, new projects, and so on. The goal here is to help maintain the relationships of contributors over time, even when they have moved on from the project for various reasons such as a new job or new life circumstances. I don't know all the details, but would anyone find value in such a program? Would anyone want to participate? Would anyone be against this? Thanks

3 2

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.

7 7

[outcome] Inline GDB pretty printing support
by Niall Douglas 08 Aug '24

08 Aug '24

Dear Boost, The biggest new feature to land into Outcome since it went ABI stable is inline GDB pretty printing support, whereby we embed into all binaries using Outcome the Python script to display the state of `result<>/outcome<>`. As Outcome uses a layered inheritance technique to match triviality of member functions from its configured types, having to click down through the layers to discover the state was always frustrating. MSVC has long shipped with a visualiser to eliminate this, so now support for GDB matches MSVC support. The relevant implementation file can be found at: https://github.com/boostorg/outcome/blob/master/include/boost/outcome/outco… I would appreciate any testing and reporting of any issues or bugs before the 1.86 bugfix window closes. It should "just work" once you have enabled inline script loading in your `.gdbinit`. Thanks, Niall

10 19

[release] Master branch is closed for ALL changes
by Marshall Clow 08 Aug '24

08 Aug '24

Please do not commit anything to the master branch. Other branches are always fine. The 1.86.0 release is scheduled for next Wednesday, 15-Aug. — Marshall

2 1

How to use the O(1) remove_edge(typename Config::out_edge_iterator iter)
by hermann＠stamm-wilbrandt.de 08 Aug '24

08 Aug '24

I looked at runtime statements here: https://www.boost.org/doc/libs/1_85_0/libs/graph/doc/using_adjacency_list.h… Fore remove_edge() there is no O(1) option listed. On the other hand in Boost graph code I see this O(1) remove_edge() in boost/graph/detail/adjacency_list.hpp: template < class Config > struct directed_edges_helper { ... // O(1) inline void remove_edge(typename Config::out_edge_iterator iter) { std::cerr << "foobar" << std::endl; typedef typename Config::graph_type graph_type; graph_type& g = static_cast< graph_type& >(*this); typename Config::edge_descriptor e = *iter; typename Config::OutEdgeList& el = g.out_edge_list(source(e, g)); el.erase(iter.base()); } }; So my questions is for which graph and how I can make use of that O(1) function to remove an edge. It seems to be for directed graph only. While I need it for undirected graph, being able to use that O(1) function for directed graph would be a first step. Regards, Hermann Stamm-Wilbrandt.

1 2

GPU Library Utilities
by Matt Borland 07 Aug '24

07 Aug '24

By popular demand Boost.Math has begun adding support for CUDA (NVCC and NVRTC) and SYCL. Unfortunately to use all of these platforms you can not really use std:: as CUDA has utilities (e.g. <type_traits>) in cuda::std::, containers (e.g. tuple) in thrust:: and mathematical functions in the global namespace. There are also completely missing features like <limits>. To work with this we have started creating new headers that implement these features and workarounds such as: 1) limits: https://github.com/boostorg/math/blob/develop/include/boost/math/tools/nume… 2) Tuple: https://github.com/boostorg/math/blob/develop/include/boost/math/tools/tupl… 3) General configuration: https://github.com/boostorg/math/blob/develop/include/boost/math/tools/conf… Now in the code base for example instead of using std::pair you use boost::math::pair which aliases to either thrust::pair or std::pair depending on context. As we continue to build out this support we know we are going to create more headers for compatibility, and feature completeness. I thought these could be useful to other libraries so I asked John Maddock about adding copies of them to Boost.Config. He said that's not an unreasonable home for them, but I should consult the ML. My questions then are: 1) Would these utilities be useful to you? 2) If yes, do you think that Boost.Config is the right home for them? I posted a similar question on Slack yesterday and Joaquin suggested Boost.Compute. I don't think that's the right fit because these would be out of scope, the library is extremely heavy, and it's been over 5 years since the last commit from a maintainer. I would also rather not propose and go through review on a Boost.GPU_Utils, but with sufficient demand it could be worth the effort. Please let us know what you think, and thanks for your time. Matt

4 5