- Boost - lists.boost.org

[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