April 2024 - Boost - lists.boost.org

Emitting complete type information in boost-python docstrings
by Jakob van Santen 29 Apr '24

29 Apr '24

Hello, I’m not sure if this is the right forum for this question, but here goes: I work on a large scientific codebase that is heavily tied to boost, and that most users interact with via boost-python. Lately I have been working on generating PEP 484 type stubs for the ~1000 classes it exposes in order to enable static type checking and code completion in editors. This required some modifications to boost-python itself in order to get complete type information into the generated docstrings, where it can be consumed by external tooling to generate stubs: https://github.com/boostorg/python/pull/417 I have found this quite useful, and suspect it might be useful for others as well to have it in a Boost release. Can anyone give me a pointer as to how to make that happen, or let me know where or whom I should be asking instead? I asked on cplusplus-sig(a)python.org <mailto:cplusplus-sig@python.org>, which was the place many years ago, but that list seems to have died out. Many thanks in advance! Cheers, Jakob ------------------------------------------------------- Jakob van Santen DESY - Deutsches Elektronen-Synchrotron Platanenallee 6, D-15738, Zeuthen Office 2L/32 +49 (0)33762-7-7233 -------------------------------------------------------

2 1

BOOST_THREAD_HAS_EINTR_BUG...
by David Bien 26 Apr '24

26 Apr '24

Not really sure where to bring this issue up. I have a singleton globals object with a session manager, share manager, etc. that is destroyed atexit() on final reference release. There are a few mutexes in the implementation. This functions fine on Windows, MacOS, etc - the globals object is released during atexit() and shutdown proceeds normally. Under Linux when BOOST_THREAD_HAS_EINTR_BUG is defined we SIGABRT at this: ~mutex() { BOOST_VERIFY(!posix::pthread_mutex_destroy(&m)); } The verify fails and we abort(). When I define BOOST_THREAD_HAS_NO_EINTR_BUG we do not abort - which means that posix::pthread_mutex_destroy() returns 0 in the case where BOOST_THREAD_HAS_NO_EINTR_BUG is defined and returns non-zero in the case of it not being defined. Guidance? Also point me at a better place for this discussion if there is such a place. Thanks, David Bien

3 10

question about singleton_pool
by 李重斌 26 Apr '24

26 Apr '24

I want to use singleton_pool to manage memory. This is just an example which tests it. My question: the first time i allocate 100 spot object, and free them. If i allocate some spot objects, and the number of them is less than 100. no more memory is needed, there is no need to allocate memory from os again. but the fact is another memory block is allocated. The first block is 4016 bytes (sizeof(Spot) = 40), the second block is 8016 bytes. This is not as my imagine. Is there something wrong with these code? ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// std::cout << "size of Spot " << sizeof(Spot) << " bytes\n"; std::cout << "test singleton_pool firt time\n"; const size_t NumSpots = 100; Spot* p1 = static_cast<Spot*>(spot_pool::ordered_malloc(NumSpots)); for (size_t i = 0; i < NumSpots; i++) { p1[i].x = 1; p1[i].y = 1; } spot_pool::ordered_free(p1); std::cout << "test singleton_pool second time\n"; Spot* p2 = static_cast<Spot*>(spot_pool::ordered_malloc(NumSpots/2)); for (size_t i = 0; i < NumSpots/2; i++) { p2[i].x = 2; p2[i].y = 2; } spot_pool::ordered_free(p2); /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

1 0

UUID design discussion
by Peter Dimov 26 Apr '24

26 Apr '24

We've been discussing some UUID design issues in, well, issues in the Uuid repo, namely https://github.com/boostorg/uuid/issues/96 and, for context, https://github.com/boostorg/uuid/issues/113. This topic might be of wide interest to developers, so I thought it would be better to have this list know about it. Anyone who has an opinion on the matter is welcome to express it in the issue, or here. In addition to the questions raised in #96, namely, how should the constructors and the accessors of `uuid` look like (once we somehow move away from the public `data` member), here are some more topics of interest: * Should a default-constructed `uuid` remain uninitialized, or should the default constructor produce the nil Uuid? (Uninitialized is not a good look in 2024 because safety. On the other hand, `new uuid[ 1048576 ]` will start doing a `memset`.) * At the moment wide strings are processed by the name generators by converting every wchar_t to 32 bit, then hashing the bytes, zeroes and all. This doesn't strike me as correct. I think that the string should be converted to UTF-8 on the fly (with 32 bit wchar_t assumed UTF-16 and 32 bit wchar_t assumed UTF-32.)

5 11

Re: [boost] modern logic classes
by g.peterhoff＠t-online.de 25 Apr '24

25 Apr '24

>> Hello, >> I would like to provide modern logic classes, please see https://github.com/boostorg/logic/issues/30 >> What are your opinions/comments on this? > Interesting idea. > But rather than messing with tribool, I'd prefer to just see a new library quadbool. I would also like tribool to be removed. But until then it still needs to be supported. regards Gero

1 0

[stacktrace] boost_stacktrace_from_exception on non-x86
by Tim Haines 24 Apr '24

24 Apr '24

This feature is guarded by BOOST_STACKTRACE_ALWAYS_STORE_IN_PADDING, but that is only enabled on x86 ( https://github.com/boostorg/stacktrace/blob/a33e198cf660c213e700d6f050a4641…) This means that ./bootstrap.sh --with-toolset=gcc --with-libraries=stacktrace ./b2 install threading=multi toolset=gcc always fails to build on non-x86 platforms. There are three current workarounds: 1) set boost.stacktrace.from_exception=off 2) set BOOST_STACKTRACE_LIBCXX_RUNTIME_MAY_CAUSE_MEMORY_LEAK 3) build with threading=single (1) prevents me from using this feature. (2) shouldn't be needed on it's face because I'm using gcc/libstdc++. (3) affects more than stacktrace. Is this an incidental error, or is there a reason I wasn't able to deduce as to why this feature can't be used on non-x86+libstdc++? It seems like the check for libc++ on non-x86 can't be entirely done at compile time. I definitely understand wanting to alert users to the dangers of using this feature, but there also doesn't seem to be a good way of detecting the presence of libc++ at compile time (hence the need for https://github.com/boostorg/stacktrace/blob/a33e198cf660c213e700d6f050a4641… ). Thanks. - Tim

1 0

Boost board update on website, twitter, etc.
by David Sankel 21 Apr '24

21 Apr '24

Hi all, We're overdue for a Boost website/Twitter status update as it relates to the board. In summary: - The board approved pointing boost.org to C++ Alliance servers running the new website once it's ready - The board is accepting a contribution from the C++ Alliance to upgrade the @Boost_Libraries Twitter account to premium, which simplifies delegation of credentials for posts - The C++ Alliance made their @BoostLibraries Twitter account private which means only its subscribers will see its posts. The website decision was made in the 3/28 board meeting which followed the 3/13 meeting where several on boost-dev were invited to the discussion. You can read the minutes here <https://docs.google.com/document/d/1zMKUX3nfdcOXT6nUIU4M_YRlCU4ywGoG40ouo3I…> . The website decision was not easy. There wasn't consensus in boost-dev nor on the board itself (it passed with 3 in favor, 2 against, and 1 abstention). However, a needed decision was made and I invite everyone to rally behind it and support its success. I want to thank Vinnie and those working for the C++ Alliance for their major Boost website contributions. I want to acknowledge the reviewers, active Boost authors, review managers, folks making releases, bug reporters, infrastructure maintainers, and the many others that contribute to Boost in various ways. These people constitute the Boost libraries project whose consensus is the primary means of community-wide decision making. The Boost Steering Committee (and now the Boost Foundation) was created by the Boost libraries project to make such decisions *only in the rare case of community deadlock*. While the Boost board is more than happy to provide feedback and financial support for Boost libraries initiatives, the board is taking its direction from the project and not the other way around. Thanks everyone for your passionate interest in Boost and I look forward to what comes next! David, Boost Foundation Chair

2 1

On Boost and modules: second part
by Ruben Perez 19 Apr '24

19 Apr '24

Hi all, Following the recent discussion on Boost and C++20 modules, I've been performing further investigations on the possible benefits and costs of offering module support in Boost. I've summarized my findings here: https://anarthal.github.io/cppblog/modules2 TL;DR: * While there isn't too much benefit for clean builds, incremental builds tend to be much faster with modules. * Right now, modularizing requires an effort for each modularized library. * Writing CMake files for module consumption won't be trivial. I'd like to know everyone's opinion on this: do you think these efforts would make sense? In the mid-term, this will require authors to review and merge module-related PRs, at the very least. I'm especially interested in hearing René and Peter's opinions, as maintainers of B2, Boost.CMake and many other core parts (as well as other authors'). If the community decides these efforts may be worthwhile, I volunteer to perform most of the required work. My first step would be to create a working prototype with a modularized Boost.Url (as a maintained, separately compiled library, with non-trivial dependencies), together with CMake tooling, to spot any pitfalls I've missed during my analysis. I'd also like to drag any present MSVC developers' attention on this bug which has nasty consequences on code like Asio: https://developercommunity.visualstudio.com/t/Using-%5f%5ftry-in-an-inline-… Thanks, Ruben.

4 4

[release] Boost 1.85.0 Release Candidate 3 is available
by Marshall Clow 18 Apr '24

18 Apr '24

The third release candidates for the 1.85.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.85.0/source/> The SHA256 checksums are as follows: e712fe7eb1b9ec37ac25102525412fb4d74e638996443944025791f48f29408a boost_1_85_0_rc3.zip 7009fe1faa1697476bdc7027703a2badb84e849b7b0baad5086b087b971f8617 boost_1_85_0_rc3.tar.bz2 16d16b9658753117c1434e5450c5eac194957f4b6d0b390b9d07900d37c115a4 boost_1_85_0_rc3.7z be0d91732d5b0cc6fbb275c7939974457e79b54d6f07ce2e3dfdd68bef883b0b boost_1_85_0_rc3.tar.gz The changes from RC1 are: * Boost.ASIO docs generate very long file names that are not usable on Windows. * Boost.Program options does not build in C++23 mode on clang truck (to be clang 19 before boost 1.86.0 is released) Note: It is possible that this is a bug in clang, and it’s in a clang that is not released yet. * Boost.Log has some broken links in its documentation. * A meaningless change to Boost.Array (add a space to a test file) Apparently the RC2 tarballs were mis-buiilt; some of them were missing the required changes. I believe that RC3 resolves that problem. 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

10 25

A base64 library?
by Ruben Perez 17 Apr '24

17 Apr '24

Hi all, I've been thinking of writing a base64 encoder/decoder library for some time. I first found the need when writing ServerTech chat (https://github.com/anarthal/servertech-chat) and I couldn't find a library that suited my needs. All the libraries I could find were either forgotten one-day projects with no tests, or private parts of something bigger. >From this issue from Beast (https://github.com/boostorg/beast/issues/1710) it looks like this could be useful to people. My idea would be writing something that is: * Boost quality - extensive testing and fuzzing. * Configurable. My use case in ServerTech required me to not output padding chars, for instance. * Support for a streaming API. * Support for calling in a constexpr context. * I'd prefer to focus on doing base64 only and doing it well, rather than targeting arbitrary bases. I don't have any sample code yet. Following our recommendations, I'm only determining interest. My questions are: * Do you think a library like this could be useful to the C++ community? * If the answer to the above is yes, do you think it could belong to Boost, or would be better as a standalone library? Regards, Ruben.

13 30