- Boost-users - lists.boost.org

[boost::locale or boost::nowide] C++23 char8_t. How to convert std::u8string <-> std::string?
by Georg Gast 02 Sep '25

02 Sep '25

Hi, as c++23 is now way out of the door and c++26 is already on the horizon, is there any thing in the boost libraries cor the "new" u8 literal and the new u8strings? I can only find mentioning char8_t in context of boost::filesystem. https://www.boost.org/doc/libs/latest/libs/nowide/doc/html/index.html#using For std::filesystem::path available since C++17 there is no way to imbue a locale. However the u8string() member function can be used to obtain an UTF-8 encoded string from a path. And to obtain a path from an UTF-8 encoded string you may use std::filesystem::u8path or since C++20 one of the path constructors taking a char8_t-type input. But it seems there is nothing like narrow() or widen() to convert from std::u8string <-> std::string (needed for non char8_t aware libraries). Think Win32 API. Is the only recommendation: Just stay on std::string and ignore char8_t? Still in 2025? Even with boost libraries? Bye Georg

2 1

2 windows build fails to find zlib,bzip2,zstd,xz(lzma)
by Michael Murphy 27 Aug '25

27 Aug '25

boost wont detect my cli-args or use the user-config.jam whats the problem here? i see bzip is detected finally, is that because it is bz2.lib and not bz2d.lib? zlib is producing zlibd.lib shouldnt that still work, or do i need the cmake cli-arg to specify debug, i thought it would generate right if i use debug build in msvc. D:\Lib\zlib-1.3.1>dir .\bld\Debug Volume in drive D is đ Volume Serial Number is 2E57-A369 Directory of D:\Lib\zlib-1.3.1\bld\Debug 08/26/2025 07:22 AM <DIR> . 08/26/2025 07:22 AM <DIR> .. 08/26/2025 07:22 AM 69,120 example.exe 08/26/2025 07:22 AM 954,368 example.pdb 08/26/2025 07:22 AM 61,440 minigzip.exe 08/26/2025 07:22 AM 978,944 minigzip.pdb 08/26/2025 07:22 AM 210,944 zlibd.dll 08/26/2025 07:22 AM 9,699 zlibd.exp 08/26/2025 07:22 AM 16,746 zlibd.lib 08/26/2025 07:22 AM 1,028,096 zlibd.pdb 08/26/2025 07:22 AM 321,764 zlibstaticd.lib 08/26/2025 07:22 AM 94,208 zlibstaticd.pdb 10 File(s) 3,745,329 bytes 2 Dir(s) 746,667,651,072 bytes free b2.exe --toolset=msvc-14.3 --build-type=complete variant=debug address-model=64 threading=multi link=shared runtime-link=shared -j 14 -sZLIB_INCLUDE="D:/Lib/zlib-1.3.1" -sZLIB_LIBPATH="D:/Lib/zlib-1.3.1/Debug" -sBZIP2_INCLUDE="D:/Lib/__staging__/bzip2_1.0.8" -sBZIP2_LIBPATH="D:/Lib/__staging__/bzip2_1.0.8/bld/Debug" -sLZMA_INCLUDE="D:/Lib/__staging__/xz_5.8.1/src/liblzma" -sLZMA_LIBPATH="D:/Lib/__staging__/xz_5.8.1/bld/Debug" -sZSTD_INCLUDE="D:/Lib/__staging__/zstd_0.4.2/lib" -sZSTD_LIBPATH="D:/Lib/__staging__/zstd_0.4.2/bld/lib/Debug" -sICU_PATH="D:/Lib/icu" -sICU_LINK_LIB_PATH="D:/Lib/icu/lib64" ... - has_icu builds : no [2] - zlib : no [2] - bzip2 : yes [2] - lzma : no [2] - zstd : yes [2] - sfinae_expr : yes [2] using zlib : 1.2.13 : # command <include> D:/Lib/zlib-1.3.1 <library-path> D:/Lib/zlib-1.3.1/bld/Debug ; using bzip2 : 1.0.8 : # command <include> D:/Lib/__staging__/bzip2_1.0.8 <library-path> D:/Lib/__staging__/bzip2_1.0.8/bld/Debug ; using lzma : 5.4.3 : # command <include> D:/Lib/__staging__/xz_5.8.1/src/liblzma/lzma <library-path> D:/Lib/__staging__/xz_5.8.1/bld/Debug ; using zstd : 1.5.5 : # command <include> D:/Lib/__staging__/zstd_0.4.2/lib <library-path>D:/Lib/__staging__/zstd_0.4.2/bld/lib/Debug ;

2 1

Boost 1-89 + GCC 15.2 (MSYS2 ucrt64, POSIX) – thread_local static_assert with Boost.Math
by Ivo Celmans 22 Aug '25

22 Aug '25

Hello, After updating to Boost 1.89 I can no longer build my code that uses boost::math::zeta() with a boost::multiprecision::mpfr_float custom type (dynamic backend). The compiler fails with: static assertion failed: Your platform does not support thread_local with non-trivial types, last checked with Mingw-x64-8.1, Jan 2021. Please try a Mingw build with the POSIX threading model, see https://sourceforge.net/p/mingw-w64/bugs/527/ I use Windows 11, MSYS2 ucrt64 toolchain GCC 15.2.0 (Thread model: posix) . Boost also installed by MSYS2 ucrt64. Building from VS Code tasks with a flag -pthread Has anyone else encountered this with Boost 1.89 on MinGW-w64? Are there recommended compiler flags or things to work around it? For now I can only downgrade to Boost 1.88 - compile without problems. Best regards, Ivo. e ivo.celmans(a)gmail.com

2 1

[release] Boost 1.89.0
by Marshall Clow 14 Aug '25

14 Aug '25

Release 1.89.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. The release contains one new library: * Bloom: Bloom filters, from Joaquín M López Muñoz. as well as numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.89.0> You can also download directly from: <https://archives.boost.io/release/1.89.0/source/> To install this release on your system, see <http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. -- The Boost Release Team Marshall Clow, Glen Fernandes, Ion Ion Gaztañaga

1 0

Why no "w != NULL" assertion before boost/intrusive/rbtree_algorithms.hpp:511 like before the line 476?
by achinkoff＠gmail.com 05 Aug '25

05 Aug '25

Boost version: latest release file: boost/intrusive/rbtree_algorithms.hpp function: rebalance_after_erasure_restore_invariants in this if-branch ``` if(x == x_parent_left){ //x is left child ``` there is "w != NULL" assertion before variable 'w' access: ``` BOOST_INTRUSIVE_INVARIANT_ASSERT(w); if(NodeTraits::get_color(w) == NodeTraits::red()){ ``` but in else-branch there is no same assertion before variable 'w' access: ``` if(NodeTraits::get_color(w) == NodeTraits::red()){ ``` Why? Are there no assertion in else-branch intentionally due to the rbtree structure itself? Thanks.

1 0

[Transitive Dependencies] Assessing Secondary Dependency Impact on Primary Modules
by joseph.curran＠gehealthcare.com 29 Jul '25

29 Jul '25

Hello, We’re currently evaluating the impact of continuing to use an older version of Boost by reviewing fixes and changes introduced in later versions. While our application has several direct dependencies, the bcp tool reveals that we also pull in dozens of indirect (transitive) dependencies. Ideally, we’d like to limit our review to the release notes and fixes for the direct dependencies—focusing on how our application uses those modules directly. However, we’re concerned about missing issues in secondary dependencies that could affect the behavior of the primary modules we depend on. For example: Our application uses moduleA, which internally includes moduleB. If moduleB had a memory leak that was fixed in a later release, how can we determine whether moduleA was impacted by that issue - and whether our application was indirectly affected? Questions: Is there an efficient way to identify whether such secondary dependency issues have a downstream impact on the primary modules? That is, without deep diving into both moduleA and moduleB code bases and seeing if the issues/fixes apply. Are there any Boost policies or guidelines stating whether maintainers of a primary module are expected to review and address issues in their transitive dependencies? Any insights or suggestions would be greatly appreciated. Thanks, Joe

1 0

Polygon - Voronoi - clip to rectangular bounding box
by neil.j.chisholm＠gmail.com 20 Jul '25

20 Jul '25

Hello I am a hobby programmer and I hope to make use of the polygon library to procedurally generate voronoi diagrams for the purpose of defining world maps in a videogame. My use case includes a requirement that the voronoi diagram be clipped to a rectangular bounding box. The corollary to this requirement is that every voronoi cell is therefore (as a result of being clipped to the bounding box where necessary) a complete convex polygon. By this I mean that an edge must not extend outside the bounding box. If the edge would extend beyond the bounding box, it must be be clipped to the bounding box creating a new vertex at the intersection of the edge and the bounding box. I believe there would also need to be a vertex created at each corner of the bounding box. In order for a voronoi cell to be a complete convex polygon, new edge(s) must be created which run between the newly created vertices. My understanding is that the polygon library does not include a method to clip edges to a bounding box. Do you have any recommendations about how to approach defining a method which does so? - It should be possible to define the rectangular bounding box dimensions similarly to how points and segments are defined - For the sake of efficiency I assume it would be appropriate only to consider edges which extend beyond the given bounding box - While a general solution should probably be able to clip parabolic edges, my use case will likely only involve sites comprised of points (no segments) so a solution clipping straight line edges only would be sufficient for my own purposes If you have any thoughts I would be very grateful to receive them. Many thanks in advance.

1 0

[release] Boost 1.89.0 beta 1 released
by Marshall Clow 17 Jul '25

17 Jul '25

Boost release 1.88.0 beta 1 is now available at: https://archives.boost.io/beta/1.89.0.beta1/source/ The SHA256 checksums are: 9ece9af2b243f90b76f679b278b512b6589c7843e4dd54cffcb719bbc0801998 boost_1_89_0_b1.tar.bz2 bf45af4a58f39c2ec374ef6e70b26859b786ba2ed087bc869d92a2b4de14e0d2 boost_1_89_0_b1.zip f255b4a31558b3fb81be1dc7e8b367fb9997dbe5e71da98a730c681377abffa9 boost_1_89_0_b1.7z 984ee193ddf192795ba635d4c73b2b43e1e596995d7ce5519a3a72fab9bc0b40 boost_1_89_0_b1_rc1.tar.gz Release notes (still need updates): https://original.boost.org/users/history/version_1_89_0.html Please try the beta and report any problems you encounter. Thanks to everyone who contributed to the release. -- Boost Release Team

1 0

lowest_layer() is deprecated in boost::beast, replaced by boost::beast::get_lowest_layer(), but still in use by boost::asio:ssl::stream
by Klebsch, Mario 14 Jul '25

14 Jul '25

Hi, The boost libraries beast and asio seem to disagree on whether a socket/stream should offer the lowest_layer() method or not. Boost::beast::tcp_stream has only private versions of this method and the associated typedef lowest_layer_type, while e.g. boost::asio::ssl::stream still requires this method. The replacement get_lowest_layer() is only offered in beast. For boost::asio::ssl::stream this is handled by boost::beast::tcp_stream declaring boost::asio::ssl::stream as friend, so offering access to lowest_layer(). But I have my own ssl stream, based on a different SSL library than openssl, and this stream class is also (because it is based on boost::asio::ssl::stream) dependant on lowest_layer(). I think, boost::beast and boost::asio should agree on whether to deprecate lowest_layer() and offer get_lowest_layer(), or not. Klebsch Mario Funktion | R&D Tel: +49 (0) 531 38 701 718 Raum: Braunschweig, E20 Diese E-Mail und die an sie angehängten Dateien sind ausschließlich für Personen oder Institutionen bestimmt, deren Namen oben aufgeführt sind. Sie können Informationen enthalten, die durch das Berufsgeheimnis geschützt sind und deren Weitergabe strengstens untersagt ist. Jede elektronische Nachricht kann geändert werden. ACTIA lehnt jede Verantwortung für diese Nachricht ab. Der Inhalt dieser Nachricht stellt keine Verpflichtung seitens unseres Unternehmens dar. Wenn Sie kein Empfänger sind, weisen wir Sie darauf hin, dass das Lesen, Vervielfältigen oder Verteilen strengstens untersagt ist. Wir bitten Sie daher, uns umgehend über diesen Brief zu informieren und diese Nachricht sowie eventuell beigefügte Unterlagen aus Ihrem Postfach zu löschen. Danke. This e-mail and the files attached to it are intended exclusively for persons or institutions whose names are listed above. They may contain information that is protected by professional secrecy and the disclosure of which is strictly prohibited. Any electronic message can be modified. ACTIA declines all responsibility for this message. The content of this message does not represent a commitment on the part of our company. If you are not a recipient, we would like to point out that reading, copying or distribution is strictly prohibited. We therefore ask you to inform us immediately about this letter and to delete this message and any accompanying documents from your mailbox. Thank you.

1 0

Free threaded python support with PEP 779
by george.sykes＠connectorsubsea.com 09 Jul '25

09 Jul '25

Hi, With Python 3.14 introducing free threaded python I was wondering if anyone's had a chance to try this out with Boost Python? Seems like it should be able to help us increase performance on certain types of tasks but not sure if Boost Python supports using the functionality. If not, i'll go give it a crack and see what it's like. Best wishes George

1 0