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