November 2025 - Boost - lists.boost.org

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

24 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 21

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

Boost Libraries are Obsolete
by Vinnie Falco 18 Nov '25

18 Nov '25

I believe some Boost libraries become obsolete by newer versions of C++. For example, boost::filesystem, Boost.CharConv, and Boost.Variant could be considered obsolete in versions C++17 and later as these facilities are in the standard. It can be tricky to figure out what is obsolete. Is boost::shared_ptr obsolete in C++11? Probably not since it has features not found in the standard. Anyway, I'm not trying to figure this out for all the libraries. For boost.org it might be nice to let users specify the "minimum version of C++" which they use. And they can opt in to filtering the Libraries based on this minimum version. Someone who is using C++23 can choose not to see libraries like Boost.Align, Boost.Assign, or Boost.Atomic. We will need to add metadata to each library's repository to know the maximum version. What do you all think about this? -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

4 6

lists.boost.org - email is showing up for some registered users instead of name
by Andrej 17 Nov '25

17 Nov '25

Hi! Noticed posting on `Boost-users` that emails are showing up for some users, though they have a name in their profiles. Which is undesirable, since those pages are publicly available. E.g. see: https://lists.boost.org/archives/list/boost-users@lists.boost.org/thread/JB… https://lists.boost.org/archives/list/boost-users@lists.boost.org/thread/LD…

3 7

utility::string_view and core::detail::string_view
by Vinnie Falco 17 Nov '25

17 Nov '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

13 31

boost.org/patches no longer exists
by Tim Haines 15 Nov '25

15 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

1 0

The Master branch is now CLOSED for the beta release
by Marshall Clow 15 Nov '25

15 Nov '25

Please do not commit or merge to the master branch The Beta RC1s will be available later today. — The release managers.

4 6

[release] Boost 1.90.0 beta 1 released
by Marshall Clow 14 Nov '25

14 Nov '25

Boost release 1.90.0 beta 1 is now available at: https://archives.boost.io/beta/1.90.0.beta1/source/ The SHA256 checksums are: 8072831c2c54c7e0e99c69e934b5694574565dd435de19a0a43f7bf7dabad71b boost_1_90_0_b1.zip d1754f544e83418c2b5fe18245666830088948cb3629d2b346d56f31c71138e5 boost_1_90_0_b1.tar.bz2 c94235eb00edc732253d3ae8000a489ffc5773f34cd98bd7645d54cb4ae2482a boost_1_90_0_b1.7z 0f55a646eaed4daf110eeec7c2c70e2c7058efa77eef31137248a6e2cf1412da boost_1_90_0_b1.tar.gz Please try the beta and report any problems you encounter. Thanks to everyone who contributed to the release. -- The release managers

5 5

Boost.Decimal Review Result.
by John Maddock 10 Nov '25

10 Nov '25

First off a big thanks to all the folks who participated in the review process, and of course to Matt and Chris for submitting the library. Then the headline news: with 8 favorable reviews, and two equivocal ones, Boost.Decimal is ACCEPTED into Boost. There were two main contentious issues: 1) Cohort support: several reviewers asked for cohort support and one thought that printing the actual cohort should be the default. I know that Matt has been working on support for cohort IO, on the basis that the notion of cohorts take some getting used to, and that libraries should generally make the easy stuff easy, I' happy for this to NOT be the default. 2) Binary-decimal conversion. This was discussed in some depth during the review, so I won't try to repeat here. Matt has agreed to document the issue, and to make binary-decimal conversion non-straightforward (ie strongly discouraged), I'm also satisfied that the interface can be extended (in a non-breaking way) to support multiple conversion methods at a later date should there prove to be demand. Given the difficulty of implementing those methods correctly, this sounds like a reasonable compromise to me at present. I've filed all the issues raised by reviewers as issues so folks can track their progress, they are: * Cohort IO support: https://github.com/cppalliance/decimal/issues/1218 * Document what a normalized number is: https://github.com/cppalliance/decimal/issues/1217 * Document samequantum behavior: https://github.com/cppalliance/decimal/issues/1216 * Do we need issignalling, is the signature correct: https://github.com/cppalliance/decimal/issues/1215 * Better document {fmt} support: https://github.com/cppalliance/decimal/issues/1214 * Financial examples need explanatory text: https://github.com/cppalliance/decimal/issues/1213 * Document what bit conversion do: https://github.com/cppalliance/decimal/issues/1212 * Explain generic programming example, remove/rename float_equal function: https://github.com/cppalliance/decimal/issues/1211 * Improve charconv docs: https://github.com/cppalliance/decimal/issues/1210 * Clean up badly named "promotion" section in the docs: https://github.com/cppalliance/decimal/issues/1209 * Improve literal docs (and float_equal again): https://github.com/cppalliance/decimal/issues/1208 * Improve construction docs: https://github.com/cppalliance/decimal/issues/1207 * Improve examples with better hand holding rather than bare code: https://github.com/cppalliance/decimal/issues/1206 * Improve readability of binary constants: https://github.com/cppalliance/decimal/issues/1205 * Probably remove the bitwise operators: https://github.com/cppalliance/decimal/issues/1204 * Simplify numeric_limits, provide out-of-line data members: https://github.com/cppalliance/decimal/issues/1203 * Misc doc typos and corrections: https://github.com/cppalliance/decimal/issues/1202 * Correct <format> detection: https://github.com/cppalliance/decimal/issues/1201 * {fmt} unicode support: https://github.com/cppalliance/decimal/issues/1200 * Arm64 detection: https://github.com/cppalliance/decimal/issues/1199 * Codecov markup: https://github.com/cppalliance/decimal/issues/1198 * assert in charconv example: https://github.com/cppalliance/decimal/issues/1197 * Improve example descriptions: https://github.com/cppalliance/decimal/issues/1196 * More precise header usage in examples: https://github.com/cppalliance/decimal/issues/1195 * Public to_string function is undocumented: https://github.com/cppalliance/decimal/issues/1194 * Mistaken using declaration in docs (make the documentation code runable as part of the tests): https://github.com/cppalliance/decimal/issues/1193 * Testing only code in public headers: https://github.com/cppalliance/decimal/issues/1192 * charconv docs do not compile (T undefined):https://github.com/cppalliance/decimal/issues/1191 * Binary - decimal conversions: https://github.com/cppalliance/decimal/issues/1188 * Convenience string constructors: https://github.com/cppalliance/decimal/issues/1187 * Make sure decTest tests pass: https://github.com/cppalliance/decimal/issues/1186 * Rounding docs: https://github.com/cppalliance/decimal/issues/1185 Once again, many thanks to everyone involved, best, John.

5 4

[container] C++23 / C++26 Heterogeneous overloads (P2077+P2363)
by Ion Gaztañaga 10 Nov '25

10 Nov '25

Hi, In case anyone is missing them, those overloads for to [flat_][multi]set/[multi]map were recently pushed to the develop branch. Since the window for major code changes in the master branch closed at the end of October, if anyone thinks it would be valuable to have them in Boost 1.90, I'd need to ask permission to Marshall. Otherwise they will be generally available in Boost 1.91 (scheduled for April 2026). Best, Ion

1 0

[release] Boost 1.90.0 Beta 1 Release Candidate 1 is available
by Marshall Clow 09 Nov '25

09 Nov '25

The first release candidates for the 1.90.0 Beta 1 release are now available at: <https://archives.boost.io/beta/1.90.0.beta1/source/> The SHA256 checksums are as follows: 0f55a646eaed4daf110eeec7c2c70e2c7058efa77eef31137248a6e2cf1412da boost_1_90_0_b1_rc1.tar.gz c94235eb00edc732253d3ae8000a489ffc5773f34cd98bd7645d54cb4ae2482a boost_1_90_0_b1_rc1.7z 8072831c2c54c7e0e99c69e934b5694574565dd435de19a0a43f7bf7dabad71b boost_1_90_0_b1_rc1.zip d1754f544e83418c2b5fe18245666830088948cb3629d2b346d56f31c71138e5 boost_1_90_0_b1_rc1.tar.bz2 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

6 6

[move] Why not use std::addressof when available for boost::move_detail::addressof rather than undocumented __builtin_addressof
by travisp＠mailhaven.com 06 Nov '25

06 Nov '25

Hi all, I noticed that a change was made to boost::move_detail::addressof implementation to address some potential GCC compiler alignment warnings: https://github.com/boostorg/move/commit/7637429b6c361321cf0512014949f86be32… The new implementation uses GCC's __builtin_addressof (which remains purposefully undocumented, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96634 ), or uses a clever series of casts. And it doesn't take advantage of the potential existence of std::addressof. Is there any reason why not use std::addressof when it is available (since C++11)? (Aside: I ran across this because I have an unusual situation, where the new clever casts are an issue (but the previous clever implementation was alright, but presumably caused strict-alignment warnings), and using __builtin_addressof is an issue too. In all cases, std::addressof will work fine for me and seems like it would be preferable for all, when available.) -Travis

2 1

[release] Master branch closes TODAY for the 1.90.0 beta release
by Marshall Clow 05 Nov '25

05 Nov '25

As always, you can find the calendar here: https://www.boost.org/calendar/ — The release managers

1 0

moving TypeTraits to the boost::type_traits namespace
by Gero Peterhoff 05 Nov '25

05 Nov '25

I think we should finally move TypeTraits to the boost::type_traits namespace. This has only advantages: - clear separation from other boost libraries - the boost namespace is no longer contaminated - when providing additional TypeTraits, it is immediately clear in which namespace they must be implemented These changes would of course be elaborate, but they would bring advantages: consolidation + general review of existing TypeTraits: - are they still necessary / could they be removed? better to use std::TypeTraits - could they be implemented in a more contemporary way? Gero

2 1

boost.parser: Hitting the wall; what am I doing wrong?
by Richard 03 Nov '25

03 Nov '25

Hi Boosters, I've hit a wall while using boost.parser to parse a fractal formula file format. At this point, when I attempt to add a new rule to my grammar, msvc goes to compile the file and just sits there. It isn't hammering CPU, memory or disk, just sitting there. I let it run for like 30 minutes before I aborted it. There's no error or warning diagnostic. The details are in this issue on boost.parser: <https://github.com/boostorg/parser/issues/288> I believe separate compilation of the rules implementing my grammar would work around this problem (and give me better turnaround time on edits as I'm not changing the entire grammar as I improve it), but I was unable to get separate compilation of rules to work with boost.parser. Is separate compilation even possible? -- 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>

1 0

The Master branch will be closing for the 1.90.0 beta release on Wednesday (5-Nov)
by Marshall Clow 02 Nov '25

02 Nov '25

As always, you can find the calendar here: https://www.boost.org/calendar/ — The release managers

1 0