December 2025 - Boost - lists.boost.org

Modular B2 build status ==> missing commits from master.
by René Ferdinand Rivera Morell 26 Dec '25

26 Dec '25

I finally have some slivers of time to check in on the status of the modular build changes. As of a few minutes ago there are 34 libraries that have not merged the changes to master: ==> algorithm behind 25 commits. ==> align behind 2 commits. ==> callable_traits behind 1 commits. ==> circular_buffer behind 11 commits. ==> compute behind 12 commits. ==> convert behind 9 commits. ==> date_time behind 11 commits. ==> exception behind 14 commits. ==> foreach behind 10 commits. ==> functional behind 1 commits. ==> fusion behind 3 commits. ==> graph behind 67 commits. ==> graph_parallel behind 19 commits. ==> hof behind 2 commits. ==> icl behind 23 commits. ==> io behind 1 commits. ==> local_function behind 1 commits. ==> multi_array behind 1 commits. ==> ublas behind 37 commits. ==> parameter_python behind 7 commits. ==> phoenix behind 2 commits. ==> polygon behind 11 commits. ==> property_map_parallel behind 7 commits. ==> proto behind 9 commits. ==> range behind 13 commits. ==> safe_numerics behind 45 commits. ==> scope_exit behind 12 commits. ==> serialization behind 26 commits. ==> statechart behind 1 commits. ==> tti behind 10 commits. ==> units behind 1 commits. ==> vmd behind 11 commits. ==> xpressive behind 13 commits. Would be fantastic if the libraries update their master branches for the next release. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net

1 0

[filesystem] Boost.Filesystem now treats Cygwin as a POSIX platform (was: New errors on Cygwin)
by Andrey Semashev 25 Dec '25

25 Dec '25

Hi, Following the discussion in the "New errors on Cygwin" thread, I have now switched Boost.Filesystem to treat Cygwin as a POSIX platform. The change is now in develop and is planned to be released in Boost 1.91. As noted in that thread, this is a breaking change for Cygwin users, unless they were already using a patched Boost.Filesystem to a similar effect. Among the things that are visible to users are: * The path::value_type type has changed from wchar_t to char. As on other POSIX platforms, wide character paths will be converted to the narrow character encoding using the locale set by path::imbue. Note that since Cygwin is running on top of Windows, it will also perform character code conversion internally. It is important that locale in the Cygwin environment is configured correctly. * Path syntax now follows POSIX conventions, Windows-specific paths (e.g. UNC paths, drive names and path prefixes) are not supported. * Certain Windows-specific parts of the API will become inaccessible. Since reparse points are a Windows-only feature, file_type::reparse_file will not be reported for files. Reparse point handling is dependent on Cygwin runtime behavior. * Cygwin has its own implementation of symlinks that is incompatible with native Windows symlinks. Boost.Filesystem will now create and operate on Cygwin symlinks. * Error codes reported by Boost.Filesystem will now use POSIX errno values. There may be other differences that I forgot to mention. There is no fallback option, other than patching Boost.Filesystem or staying on an older version, and this is intentional. Making this choice user-configurable opens up too many possibilities for inconsistencies and ODR issues, especially given that Boost.Filesystem is a compiled library. It would also complicate maintenance.

1 0

B2 and Visual Studio 2026
by René Ferdinand Rivera Morell 23 Dec '25

23 Dec '25

FYI, about 14 hours ago both the develop and master branches have B2 v5.4.2. It contains the changes to support recognizing the new VS 2026 release. See <https://github.com/bfgroup/b2/releases> for the substantive changes. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net

2 2

[filesystem] New errors on Cygwin
by Gennaro Prota 23 Dec '25

23 Dec '25

Hi, I'm getting some errors from Filesystem in the Cygwin tests of DynamicBitset. I see that Filesystem is tested on Cygwin, so this is odd. Could a maintainer please have a look? Thanks. <https://github.com/boostorg/dynamic_bitset/actions/runs/20430426737/job/586…>. -- Gennaro Prota <https://prota.dev>

4 10

Cygwin patches
by David McFarland 22 Dec '25

22 Dec '25

Hi, I've created a set of patches that together allow boost to build on cygwin. - https://github.com/boostorg/asio/pull/463 - https://github.com/boostorg/context/pull/322 - https://github.com/boostorg/process/pull/533 - https://github.com/boostorg/stacktrace/pull/219 - https://github.com/boostorg/system/pull/137 I also made a tracking issue with links to all of them: - https://github.com/boostorg/boost/issues/1112

4 5

Compile failing in v1.90.0 with dynamic_bitset
by Benjamin Redelings 22 Dec '25

22 Dec '25

Hi, Software tests found a compile failing with boost v1.90 (it was just pulled in to homebrew). I filed an issue here: https://github.com/boostorg/dynamic_bitset/issues/100 Please let me know if I should be notifying someone else instead. -BenRI

3 2

[multi_index] upgrade to C++11 and potential backwards compatibility issues
by Joaquin M López Muñoz 21 Dec '25

21 Dec '25

Hi, Boost.MultiIndex has been upgraded to require C++11 a minimum, and in the process the library has been refactored to no longer use Boost.MPL and Boost.Preprocessor. The changes, benefits and potential backwards compatibility issues are explained in this external article: https://bannalia.blogspot.com/2025/12/boostmultiindex-refactored.html If you're a Boost.MultiIndex user please test this upgraded version in advance of the target Boost 1.91 release (develop branch of boostorg/multi_index) so that we have time to fix any problem that may arise. Thank you! Best, Joaquín M López Muñoz

2 2

[release] Boost 1.90.0
by Marshall Clow 15 Dec '25

15 Dec '25

Release 1.90.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: * OpenMethod: Open-(multi-)methods in C++17 and above, from Jean-Louis Leroy. 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.90.0> You can also download directly from: <https://archives.boost.io/release/1.90.0/source/> To install this release on your system, see <https://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 Gaztañaga

4 4

utility::string_view and core::detail::string_view
by Vinnie Falco 14 Dec '25

14 Dec '25

On Thu, Oct 23, 2025 at 4:17 AM Dmitry Arkhipov via Boost < boost(a)lists.boost.org> wrote: > Url's and Charconv's maintainers decided > to not play along with the charade and reference boost::core::string_view > directly with the obvious drawback that that type is not documented > anywhere. > core::detail::string_view was added because this pull request FROM 2018 (seven years ago) was rejected: https://github.com/boostorg/utility/pull/51 We really need to fix this properly. In my opinion the maintainer of utility::string_view made the wrong choice when they rejected the pull request to make the constructors more useful. The consequence is that several Boost authors now use core::detail::string_view because it better satisfies user needs. At a time when people complain that Boost has its own version of std types, it would be best if we could come together and sort this. I would like to see the change which motivated core::detail::string view get applied to utility::string_view. Then we can change core::detail::string_view to be a deprecated alias, and after one release we can remove it. This solves everyone's problem: 1. Users get a type that works 2. Folks are not triggered by having two string views 3. Every library doesn't have to lift string_view into its own namespace 4. Cross-linking in documentation becomes possible With each new version of C++ we are asking more and more of Boost users. We are asking them to opt-in to our ecosystem which includes its own types similar yet sometimes incompatible with the standard types. It is our responsibility to make sure that we respect the user's trust, and deliver types which work for them. boost::utility::string_view breaks that trust at a time when we cannot afford to alienate. The consequence of the decision not to be flexible with the utility::string_view API is that now we have two string views. We have documentation issues. We have discovery issues. There is strife within the community. Yet more and more libraries are choosing core/detail/string_view.hpp instead of utility/string_view.hpp, simply because the core version works better. It is in the project's best interest to show the C++ community writ large that we can adapt and satisfy user needs. Lets do that by resolving the two string views. Thanks

15 54

Re: utility::string_view and core::detail::string_view
by Arash Partow 14 Dec '25

14 Dec '25

Andrey Semashev via Boost wrote: > What's the point in discussing things anyway, when there are only two > opinions, yours and wrong? > Vinnie, can we please have a best comment on the Boost ML award this year? and if so can this be number be one. - Arash

1 0

[Release] The master branch is now open
by Marshall Clow 10 Dec '25

10 Dec '25

Thank to everyone for their patience. The next release cycle will begin in late February — The release managers

1 0

[release] Boost 1.90 RC1 available
by Marshall Clow 09 Dec '25

09 Dec '25

The first release candidates for the 1.90.0 release are now available at: <https://archives.boost.io/release/1.90.0/source/> The SHA256 checksums are as follows: 5e93d582aff26868d581a52ae78c7d8edf3f3064742c6e77901a1f18a437eea9 /boost_1_90_0_rc1.tar.gz 78413237decc94989bffd4c5e213cc4bf49ad32db3ed1efd1f2283bd6fb695b2 /boost_1_90_0_rc1.7z 49551aff3b22cbc5c5a9ed3dbc92f0e23ea50a0f7325b0d198b705e8ee3fc305 /boost_1_90_0_rc1.tar.bz2 bdc79f179d1a4a60c10fe764172946d0eeafad65e576a8703c4d89d49949973c /boost_1_90_0_rc1.zip 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

5 7

A proposal for a modern build-system
by Hassan Sajjad 08 Dec '25

08 Dec '25

Hi. I compiled 25 Boost libraries with C++20 header-units, including examples and Tests of a few. This resulted in a 1.44x speed-up if we exclude the scanning. Scanning was as slow as the header-unit build. I have a solution for that. I am sending this paper (Making some final edits) https://htmlpreview.github.io/?https://github.com/HassanSajjad-302/iso-pape… , which allows for a build-system to use a scanning-less approach to build header-units.This method requires only minimal modifications to the compiler and enables memory-mapped file sharing, which significantly reduces filesystem overhead and further boosts speed. My proposal for a scanning-less approach will allow HMake to have another amazing feature, monolithic Big header-units. BigHu will allow you to map all the headers from a directory to a single header-unit. This header-unit includes all these header-files and consumes them as header-files. Now, whenever the compiler requests a header-unit from this directory, the build-system instead sends this consolidated BigHu. This will not only improve the clean build speed, because of fewer process launches. But also massively boosts the rebuild speed as few header-units need to be read instead of lots of files. No source-code editing will be needed to use this feature. And you will have the option to either build a library as BigHu (if you don't mean to edit it) or as small header-units (if you are working on it). HMake will soon support compile_commands.json, which I guess can work fine with header-units. Thus you can benefit from both, faster compilation and working intelliscence. The API shown in hmake.cpp is a work in progress. HMake build-system benefits are numerous, even if we leave out the header-units support. This makes it a perfect replacement for B2. I believe we can complete the switch in the next 2 months. And if some compiler supports my paper, we get >3x faster compilation as well. Best, Hassan Sajjad

28 88

[release] Master branch is now closed for the release
by Marshall Clow 04 Dec '25

04 Dec '25

Master is closed for all changes. See the release schedule at http://www.boost.org/calendar — The release managers

1 0

[release] New procedure for Boost 1.90 release notes
by Joaquin M López Muñoz 03 Dec '25

03 Dec '25

Hi everybody, As part of the evolution of the new website, the release notes procedure for the upcoming Boost 1.90 release is changing: BEFORE * Authors contributed their release notes as PRs to the file https://github.com/boostorg/website/blob/master/feed/history/boost_1_89_0.q… whose format was **Quickbook**. NOW * Authors should contribute their release notes as PRs to the file https://github.com/boostorg/website-v2-docs/blob/develop/release-notes/boos… whose format is **Asciidoc**. The procedure should be as straightforward as always. Asciidoc is in essence a Markdown variant, and the file already has some entry examples you can copy, adapt and paste. The following Asciidoc macros are available as a replacement to similarly-called Quickbook macros used before: https://github.com/cppalliance/asciidoctor-boost?tab=readme-ov-file#macros Currently there's no easy way to obtain a preview of the upcoming release notes, but I know the team in charge is working on this. Allow me to remind authors and contributors that now is an excellent time to add your entries to the release notes. If you have any doubts please post them here, or ask at the #boost Slack group. Thank you! Best, Joaquín M López Muñoz

3 5

[release] Reminder - the master branch will close for the 1.90 release TOMORROW
by Marshall Clow 02 Dec '25

02 Dec '25

See the calendar at: https://www.boost.org/calendar/ Also, if you have release notes, please add them — The release managers

1 0

Pull requests for odeint waiting since Sep 30
by Richard 01 Dec '25

01 Dec '25

Hi, Back at the end of September when I gave a presentation on boost.odeint, I fixed a few minor things that were causing the samples to fail to build. I submitted pull requests that fixed the issues, but they've not been merged. They're not particularly complicated changes, so I am wondering what's holding up the merging of the fixes. Thanks, -- Richard -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://ComputerGraphicsMuseum.org> Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

2 1