August 2024 - Boost - lists.boost.org

[unordered] GDB pretty-printer display bikeshedding
by Braden Ganetsky 14 Aug '24

14 Aug '24

Hi all, I want some opinions on the display printout for the GDB pretty-printers I'm working on, for the Unordered library. I have a sample printout in this GitHub gist here. (https://gist.github.com/k3DW/ead86d748aa4c4bba3f9f67f09521ba5) Everything at this link is already implemented and functional in my branch. I want opinions on how it looks. I have a few specific questions for everyone, but I'll take any other comments that don't belong with these questions below. 1. For the container display format, I matched what the standard library containers do. Should the beginning be shortened to `boost::unordered_map` instead of the current display of `boost::unordered::unordered_map`? The same question applies to all of the other containers. Does the middle namespace `unordered` cause too much visual noise? 2. For the iterators, is `iterator = {...}` a good enough format? Or should this iterator also specify the container type it came from instead of just `iterator`? I prefer it as I wrote it, but I am only one member of the community. 3. Any suggestions for end iterators other than simply `{ end iterator }`? Again, I like it this way, but I want to know if other people feel similarly. 4. To print the stats, I implemented a custom GDB command called "print_stats" that behaves exactly like "print", except it prints an open-addressing container's stats instead of its elements. Is the name "print_stats" alright to use in this scenario? Or should it be something like "boost_unordered_print_stats" to mitigate against name collisions? Thanks, Braden

1 0

Bug fixed inline GDB pretty printing
by Niall Douglas 13 Aug '24

13 Aug '24

Re: my previous guide to writing inline GDB pretty printers, it turns out it had bugs. Here is how to fix them. Firstly, my thanks to Braden Ganetsky for reporting the bugs, then pair programming over Slack with me late last night to diagnose and fix the issues. We have cowritten a conversion script which we now believe is actually correct -- it takes a Python GDB pretty printer, and emits a C (not C++) header file with all the correct markup. It can be found at: https://github.com/ned14/quickcpplib/blob/master/scripts/generate_gdb_print… The first bug fixed is correct escaping: we need to double escape the original Python in the right kind of way to cause the escaped inline assembler block to emit the right escaped text for GDB to load it correct as Python. Getting the double escaping correct is tricky, but we think we have it now. The second bug fixed is correct composure of multiple inline GDB pretty printers - Braden found only the first was having any effect. It turns out this is due to a misreading of the GDB docs from https://sourceware.org/gdb/current/onlinedocs/gdb.html/dotdebug_005fgdb_005… where this example: ``` asm( ".pushsection \".debug_gdb_scripts\", \"MS\",@progbits,1\n" ".byte " XSTRING (SECTION_SCRIPT_ID_PYTHON_TEXT) "\n" ".ascii \"gdb.inlined-script\\n\"\n" ".ascii \"class test_cmd (gdb.Command):\\n\"\n" ... ``` ... does not make it clear that the string "gdb.inlined-script" is actually the unique identifier of that script used to eliminate duplicates. It needs to be unique per inlined script unless you specifically want duplicates, and our Python converter above has remedied this. Generally you ought to name it after your library and maybe possibly a git SHA or version depending on how unstable your library is, and ensure that the pretty printer matches only that version of your library. Thanks once again to Braden for his help. Note that the Outcome GDB pretty printer which has shipped in the pending Boost release is buggy and will not work properly. The next Boost release will fix it. You can of course copy the fixed pretty printer from the github repo over this Boost release. Niall

1 0

[release] Boost 1.86.0 Release Candidate 1 is available
by Marshall Clow 13 Aug '24

13 Aug '24

The first release candidates for the 1.86.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.86.0/source/> The SHA256 checksums are as follows: 2575e74ffc3ef1cd0babac2c1ee8bdb5782a0ee672b1912da40e5b4b591ca01f boost_1_86_0_rc1.tar.gz cd20a5694e753683e1dc2ee10e2d1bb11704e65893ebcc6ced234ba68e5d8646 boost_1_86_0_rc1.zip 413ee9d5754d0ac5994a3bf70c3b5606b10f33824fdd56cf04d425f2fc6bb8ce boost_1_86_0_rc1.7z 1bed88e40401b2cb7a1f76d4bab499e352fa4d0c5f31c0dbae64e24d34d7513b boost_1_86_0_rc1.tar.bz2 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

6 6

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 200

Misunderstandings about the Boost Foundation
by David Sankel 13 Aug '24

13 Aug '24

Hi all, I want to address some misunderstandings surrounding Jon Kalb’s departure, foundation revenue sources, and boost project initiatives. First, Jon’s exit from the Boost Foundation was not the result of Jon committing a code of conduct violation. Out of respect for his privacy, I don’t want to detail the rationale unless Jon agrees that it should be public. Second, Boost Foundation revenue comes from sources beyond C++Now proceeds; individual donations and corporate matches make up 41% of revenue. Finally, I’d like to address the idea that the foundation board is distracted with the conference and pays no attention to the Boost project. A lot of what we do isn’t visible, so it is understandable how someone might come to this conclusion. However, here is a sample of Boost project-specific work we’ve done over the past couple of years: - Retired an old server that was no longer being used - Brought on a contractor who provided advice on how to migrate Wowbagger’s functionality off of legacy platforms - Handled outages due to Wowbagger’s hard drive failures - Addressed a GitHub issue where a large file was exceeding our limits - Created a discourse.boost.org so the Boost community could experiment with a mailing list alternative - Solicited estimates from CDN vendors when our current sponsor said they’d no longer be able to provide free bandwidth - Held brainstorming sessions on how we could help the Boost project better meet its objectives The fact that foundation work isn’t widely known by others involved in the Boost Project is a problem. I’d like to find more effective means to communicate the good work that’s being done. – David

2 1

[config] First steps towards C++20 modules
by Antony Polukhin 12 Aug '24

12 Aug '24

Hi, C++20 modules seem to be a good tool to improve compile times and to hide the implementation details of the libraries. I've been looking throught the sources of {fmt} library. Looks like the fmt library approach to C++20 modularization seems to fit Boost quite well. How about adding the following macro to Boost: * BOOST_BEGIN_MODULE_EXPORT - starts the scope of things to export if Boost is build as a C++20 module * BOOST_END_MODULE_EXPORT - ends the scope of things to export if Boost is build as a C++20 module * BOOST_MODULE_EXPORT - for a single entity export if Boost is build as a C++20 module As a result, if Boost is build as a module the above macros are defined in the following way: #define BOOST_MODULE_EXPORT export #define BOOST_BEGIN_MODULE_EXPORT export { #define BOOST_END_MODULE_EXPORT } Helper macro BOOST_NO_CXX23_IMPORT_STD for detecting availability of `import std` also seems useful. Macro BOOST_NO_CXX20_MODULES - for notifying the libraries that compiler does not support modules or Boost modules are not compiled. With all the above macros the Boost libraries could look like: /// header #include <boost/library_that_is_known_to_not_support_modules.hpp> #ifdef BOOST_NO_CXX20_MODULES #include <boost/library_that_supports_modules.hpp> #else import Boost.LibraryThatSupportsModules; #endif #ifdef BOOST_NO_CXX23_IMPORT_STD #include <iostream> #else import std; #endif namespace boost { namespace detail { template <class T> bool try_do(const T&); } BOOST_BEGIN_MODULE_EXPORT template <class T, class From> bool try_lexiacal_convert(const From& f, T& to) { /*impl*/ } template <class T, class From> T lexiacal_cast(const From& f) { /*impl*/ } BOOST_END_MODULE_EXPORT } /// module src file export module Boost.MyLibraryName; #ifdef BOOST_NO_CXX20_MODULES #error ??? #endif #include <boost/my_library.hpp> -- Best regards, Antony Polukhin

5 14

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