November 2025 - Boost - lists.boost.org

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

14 48

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] 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

Container regression
by Vinnie Falco 30 Nov '25

30 Nov '25

boost.container now has a cyclic include dependency which is breaking all my builds -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

2 1

Histogram test failure on master branch
by Peter Dimov 28 Nov '25

28 Nov '25

I'm seeing a new failure on the master branch: 883/2538 Test #977: run-boost_histogram-histogram_ostream_ascii_test ......................................***Failed 0.00 sec /home/runner/work/boost/boost/libs/histogram/test/histogram_ostream_ascii_test.cpp(67): test 'str(h).c_str() == expected' ('BEGIN histogram(integer(0, 3, options=underflow | overflow))END' == 'BEGIN histogram(integer(0, 3, options=underflow | overflow)) +------------+ -1 0 | | 0 -1 |=== | 1 3 | ======== | 2 2 | ====== | 3 0 | | +------------+ END') failed in function 'void run_tests() [with Tag = boost::histogram::dynamic_tag]' 1 error detected. Histogram's master hasn't changed for 5 months, so this is probably caused by something else. The CI run is https://github.com/boostorg/boost/actions/runs/19686425029/job/56392904495 and it's being done in response to an Iterator change on master, although the change itself is non-functional.

3 4

[release] Master branch is now open for bug fixes
by Marshall Clow 25 Nov '25

25 Nov '25

Hi, The master branch is now open for bug fixes, test and documentation changes, but please follow the policy described in: https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy The next deadline: On December 3rd, master closes for all changes. As always, the calendar is at https://www.boost.org/calendar — The release managers

11 26

boost.org/patches no longer exists
by thaines.astro＠gmail.com 21 Nov '25

21 Nov '25

The release notes have links to relevant post-release patches linked under https://www.boost.org/patches, but that URI no longer exists. For example, https://www.boost.org/releases/1.73.0/ refers to https://www.boost.org/patches/1_73_0/0001-outcome-assert.patch Thanks. - Tim P.S. Apolgies if this is a duplicate. My previous email seems to have never made it to the list.

2 1

Re: [release] Master branch is now open for bug fixes
by Mungo Gill 21 Nov '25

21 Nov '25

I don't know if this impacts the release but when I build my own library I am seeing build errors at the moment on C++11 clang. In file included from libs/buffers/test/unit/asio.cpp:17: ./boost/asio/buffer.hpp:332:7: error: use of the 'deprecated' attribute is a C++14 extension [-Werror,-Wc++14-extensions] class BOOST_ASIO_DEPRECATED_MSG( ^ ./boost/asio/detail/config.hpp:1373:46: note: expanded from macro 'BOOST_ASIO_DEPRECATED_MSG' # define BOOST_ASIO_DEPRECATED_MSG(msg) [[deprecated(msg)]] ^ 1 error generated. (see also https://github.com/chriskohlhoff/asio/issues/1683 )

3 2

Advanced Java Full Stack Developer Course in Ameerpet | IntelliQ IT
by bajiintelliqit＠gmail.com 20 Nov '25

20 Nov '25

It’s you are looking for a Java class that is the best Java class near your location. IntelliQ IT is the best training institute to offer you a complete Java Full Stack Developer Training which is designed mainly for students, freshers, and working professionals who want to build a robust IT career. The program lasts for six months and is set in Hyderabad, where it is the leading training institute to offer such a program. The job-oriented program starts with Core Java, then goes through Advanced Java, JDBC, Servlets, JSP, Spring, Spring Boot, Hibernate, Microservices, REST API, and ends with full-stack development. The backend part has the most powerful technologies while the frontend has the most important skills like HTML, CSS, JavaScript, React, and Bootstrap plus you will also be learning about version control systems like Git and GitHub. All this combined is what makes you a full stack developer who can work on the entire cycle of applications. The teaching method at IntelliQ IT is entirely based on giving the student practical exposure, real-time projects, and hands-on assignments which will help him/her to learn the use of Java technologies in real development environments. The trainers that have a lot of experience explain the concepts together with the industry examples that make the understanding of even the toughest topics very easy. If you are from an IT background or non-IT, the systematically designed curriculum guarantees that you will be learning step-by-step from basics to advanced modules. The consultants’ personalized support is one of the things that make IntelliQ IT unique, placement assistance is another one, and then an interactive classroom environment is the third one. The students have the benefit of one-on-one guidance, preparing their resumes, interviewing practice, and getting continuous mentorship all through the training. The strong placement network of the institute helps many students find jobs in the top companies. In case you want to take your career to the next level by taking the best Java class nearby, the Java Full Stack Developer Training at IntelliQ IT is the right option for you. With a team of expert trainers, real-time projects, and career-focused guidance, IntelliQ IT guarantees

3 2

State of the art regarding bitmasks
by Ruben Perez 19 Nov '25

19 Nov '25

Hi all, I've recently found myself frustrated due to the amount of boilerplate that bitmask types require. Say, for example, asio::cancellation_type_t: https://www.boost.org/doc/libs/latest/boost/asio/cancellation_type.hpp When using enum class to avoid pouring identifiers into the parent namespace, you need to re-implement all the bitwise operators. This is not a lot of work, but is empty boilerplate, and implies adding tests and docs. Reflection may aid with this. I've written a small proof of concept: https://access_refl.compiler-explorer.com/z/jdaxf9q54 Pasting here the basics, just in case: namespace bitmasks { struct bitmask_t {}; inline constexpr bitmask_t bitmask {}; // Checks that t has our annotation consteval bool has_bitmask_annotation(std::meta::info t) { ... } template <class E> concept BitmaskType = std::is_scoped_enum_v<E> && has_bitmask_annotation(^^E); } // Intentionally in the global namespace template <bitmasks::BitmaskType E> E operator|(E e1, E e2) { using U = std::underlying_type_t<E>; return static_cast<E>(static_cast<U>(e1) | static_cast<U>(e2)); } The idea is that you use the [[=bitmask]] annotation on your enum, and you get all the operators for free. I could also add optional pretty-printing. Questions: * Do you think this is a problem worth solving, or am I being too picky? * Do we already have something similar in Boost? I've found a BOOST_BITMASK macro (https://www.boost.org/doc/libs/latest/boost/detail/bitmask.hpp) but it doesn't seem to be public. * Do you think the approach shown above is sound? In particular, operators are in the global namespace so that they work with any enum in any namespace correctly annotated. * Do you think such a small component could be useful in Boost at some point? Thanks, Ruben.

6 11