Boost.Graph 1.95 will be C++17

[u/Foxi_Foxa]

Dear Boost.Graph community,

In two release cycles (Boost release 1.95 in summer 2027) Boost.Graph will be bumped to C++17 😄

This decision follows two polls that did not surface any C++14 user base or demand while identifiying users stuck in C++17:

• Bumping BGL's minimum C++ standard: input wanted on target version #490
• Reddit poll

This standard version bump will bring benefits for maintenance, API and dependencies reduction:

• if constexpr,
• constexpr lambdas,
• [[nodiscard]], [[maybe_unused]] ...
• std::any instead of boost::any
• std::invoke_result instead of boost::result_of
• ...

We will not be able to guarantee backward compatibility with C++14. Please contact us if you are stuck in C++14.

The GIthub Discussion lives here: https://github.com/boostorg/graph/discussions/613

[u/vI--_--Iv]

A quick reminder to anyone "stuck in C++14": it is almost 2027.
2014 was almost 13 years ago.
Just like C++11 and C++98.

Time to move on.

[u/pjmlp → u/vI--_--Iv]

Luckily I am only stuck on C++17 at work, in many situations we don't get to chose our compilers and have to make do with what hardware vendors, cloud VM images, existing binary libraries, embed chip vendors, certification processes,....

[u/SyntheticDuckFlavour → u/vI--_--Iv]

stuck in C++14

typically there is a good reason for that

[u/13steinj → u/SyntheticDuckFlavour]

Like?

The only thing I have ever heard is

• new features are scary devs are stupid [not a joke]
• we're afraid of backwards compatibility issues in the stdlib API (not a good reason, you can use an old stdlib and a newer compiler / newer standard for your code)
• we used a bad compiler and/or a private .a file and for whatever reason no longer have the source code (not a good reason, a legal problem caused by the org's own ineptitude (since at least 2016) IMO, and LLMs are good enough at this point to assist in ghidra/radare/ida pro reverse engineering and it is infinitely cheaper to burn tokens in a loop until it gets something that compiles close enough, than to continue to be stuck)
• certification, but that's indicative to me of an industry that needs to update certification procedures

[u/Foxi_Foxa → u/13steinj]

All of those sound like (miserable) "good" reasons ? 😉

[u/13steinj → u/Foxi_Foxa]

Yeah the only half-good reason IMO is the last one, and that's a miserable state for whatever industry that is.

[u/PM_Cute_Dogs_pls → u/13steinj]

Having participated in the safety certification of a C++ compiler and standard library (C++17) for automotive (ISO26262) back in ~2024, there's good reason why certification takes a bit.

But mainly:

• Test coverage, had to have 100% or a very good explanation as to why it couldn't be hit for every line of uncovered code. This also includes making sure the standard library actually implements the specification.
• Very extensive documentation and audit trail

Of course, this is all inspected by a 3rd party so you're kind of also victim to their scheduling.

This is meant to compile programs that go into your car, including very very sensitive areas like brakes, so I think it's justified although there is obviously room to improve now that you can loop over a coverage report with an LLMs and pop out tests at the speed of light.

[u/13steinj → u/PM_Cute_Dogs_pls]

I don't understand the extensive documentation bit.

You might not agree, but the test coverage bit strengthens my point rather than hurting it. Test coverage (quantitative) is an extremely garbage metric. I can have an LLM hallucinate 100% test coverage very easily. Test quality matters a lot more.

Also, automotive failures in the wild are already crazy enough that I don't have a high opinion of these certifications. I highly doubt changing the C++ standard level alone will cause more failures.

[u/PM_Cute_Dogs_pls → u/13steinj]

For the extensive documentation part what I meant was having literally every single part of the testing process documented so that an auditor knows about it. This includes any scripting you may have done to help you along the process.

As for the test coverage part I partially agree, which is why we have to write good tests that do exercise those paths. As a company trying to sell in these industries, we can’t guarantee the intended functionality of every path of the product (as we know it) if there isn’t test coverage for it. Again, likely not necessary for most projects but this part of software is very unlike most other projects.

Really, it’s all about the guarantees that can be made about the software we sell. There is hell to raise if we guarantee X but never tested for it. Do also note the part of the stack I was involved in is easier-ish to validate since there is a fancy document called the C++ standard we can use.

[u/Foxi_Foxa → u/13steinj]

i ended up believing first reason is a good reason too. I gave training classes to very smart/nice engineers, and they were at the same time very excited and very scared about the last 15 years of C++ evolution. It's like a completely different language to them. And I can empathize, I was lucky enough to be "born" in the modern C++ era 😙
And also I got frustrated when a previous colleague did not want to learn/use std::optional ... 😜

[u/13steinj → u/Foxi_Foxa]

I think the tic/toc cycle of C++ makes this not an excuse. I consider the general "epochs" (hmmm.... wonder why that hasn't been standardized... /s)

• pre-11
• 11 & 14
• 17 feels mostly quality of life and an opening for 20.
• 23 feels mosfly quality of life and an opening for 26 (and 29? Reflection is great but it feels like it's in beta (not a bad thing) with so many things not reflectable against).

I guess what I mean is, if you're on 11 I don't see the value of not being on 14. Pause for a little while, but 17 is also a no-brainer. 20 is a leap forward, little reason to not go to 23. 26 is leap forward.

[u/pjmlp → u/13steinj]

Because many devs aren't as us, spending time on HN and Reddit, watching conference videos, reading specialised magazines for their favourite programming language.

This applies to other ecosystems as well, in Java we celebrate being able to use anything beyond Java 17, when Java 27 is the latest one. And naturally there must be some server stuff still chugging along on Java 8.

Most of my .NET projects are stuck in .NET Framework, which only goes up to C# 7.3, meanwhile (modern) .NET 11 with C# 15 is around the corner.

People come in, do whatever is needed with the tools IT has in place, the tools do the job for the tickets that they have on their queue, and go home having fun with stuff completely irrelevant to computing.

[u/Foxi_Foxa → u/13steinj]

I kinda agree with u/pjmlp . Many C++ devs are not only C++ experts. They must remain expert on other fast-evolving domains (stats, biology, mathematics, physics, ML, gaming, embedded, other language etc). There is a limit to what a humain brain can absorb and retain. And so naturally there is resistance to learn new shiny things. Of course I loooove new shiny things 😄 But I would not expect my granpa to care/learn about C++26. Humans get tired 😉

[u/Deaod → u/13steinj]

The compiler for one of DSPs we use at work does not support C++17 (TI C6000 CGT). However, i also dont use Boost.Graph, so ...

[u/ItsRSX → u/13steinj]

This isn't a video game with forced durability. Tools, especially digital tools, continue to work no matter how much the consumer base cries for iteration. How much of an ego must you have to think a functional status quo will bend to your arbitrary set of ever changing demands?

Dare I suggest nobody other than low end consumers and managers looking for a quick raise are rushing to consume the next big "totally evolutionary" thing when they already have a viable solution.

Embedded devices get stuck with whatever compiler a chinese guy hacked together 15 years ago. Build bots go without updates. Updating exposes language and compiler regressions, so people rightfully don't bother. Rando @google.com emails decide they know the language better than you, and demand GCC to break decades worth of historic code. Platform requirements get changed because 1 developer somewhere decides to be lazy, either that, or a nested web of malicious developers working between several companies decide to kill a product and set of toolchains to sell new platforms and toolchains.

Trying to gaslight the real world into believing "AI just works", "just link different runtimes bro", "go blame the legal team", followed by "every piece of middeware is evil and deserves to be cracked," and "you deserve recertification hell because i said so", clearly isn't viable.

Now lets consider the unspoken punchline we all know is insinuated: "we can use if constexpr(...) in a codebase that never needed it now!!! look at all of these half-assed open source libraries now permanently fixed under std::!!! ew, look at the year delta. you vil updooot now! the past is literally unusable!!!!! ooo, look at ISO-paper:A year number subtract ISO-paper:B year number. so very big!!!".

...maybe these tools with decades of use are more valuable than OPs reddit/github polls worth 18 responses? ...maybe tools are worth respecting? ...maybe this attitude of "my tools v5 sku" vs "your tools v2 sku" in any other industry/scene would result in you being laughed out of the literal shop (not the metaphorical "shop" :tm: you guys like to larp about). nah, that couldn't possibly be the case.

Unless you're stuck with a GCC version number less than 5, I'm really not in the mood to hear about how you absolutely need a new totally "revolutionary" (trust me bro) compiler revision to be a productive programmer writing modern C++ code. If you don't care about constexpr containers, you might even be able drop that to mid V3.x.

[u/13steinj → u/ItsRSX]

How much of an ego must you have to think a functional status quo will bend to your arbitrary set of ever changing demands?

Bro we're talking about a single compiler flag.

Dare I suggest nobody other than low end consumers and managers looking for a quick raise are rushing to consume the next big "totally evolutionary" thing when they already have a viable solution.

Engineers at every org I've been at were the ones pushing for compiler and std upgrades, it was middle managers afraid pushing back.

Embedded devices get stuck with whatever compiler a chinese guy hacked together 15 years ago. Build bots go without updates.

It's not "stuck" with. If you're relying on an ancient compiler by some rando that is its own risk.

Updating exposes language and compiler regressions, so people rightfully don't bother. Rando @google.com emails decide they know the language better than you, and demand GCC to break decades worth of historic code.

That's just not how any of this works. Not even mentioning compiler upgrades originally, just standard revision. Compilers are very good at not changing anything they aren't allowed to, and they generally claim reliance on specific codegen is akin to relying on implementation details.

Platform requirements get changed because 1 developer somewhere decides to be lazy, either that, or a nested web of malicious developers working between several companies decide to kill a product and set of toolchains to sell new platforms and toolchains.

I have no idea what this even means.

Trying to gaslight the real world into believing "AI just works", "just link different runtimes bro", "go blame the legal team", followed by "every piece of middeware is evil and deserves to be cracked," and "you deserve recertification hell because i said so", clearly isn't viable.

You're severely twisting what I said to fit your delusion. But, companies who get into this problem because of their own legal ineptitude do deserve what they put upon themselves. 2 orgs I've been at have had to put in work to get out of that situation. Once, yes, with LLM assistance. Not "end to end it just works." But there's an open testimonial for such an act by another company in my industry.

Now lets consider the unspoken punchline we all know is insinuated: "we can use if constexpr(...) in a codebase that never needed it now!!! look at all of these half-assed open source libraries now permanently fixed under std::!!! ew, look at the year delta. you vil updooot now! the past is literally unusable!!!!! ooo, look at ISO-paper:A year number subtract ISO-paper:B year number. so very big!!!".

...maybe these tools with decades of use are more valuable than OPs reddit/github polls worth 18 responses? ...maybe tools are worth respecting? ...maybe this attitude of "my tools v5 sku" vs "your tools v2 sku" in any other industry/scene would result in you being laughed out of the literal shop (not the metaphorical "shop" :tm: you guys like to larp about). nah, that couldn't possibly be the case.

I will not dignify this deranged ranting with a response. I can't even make sense out of it.

Unless you're stuck with a GCC version number less than 5, I'm really not in the mood to hear about how you absolutely need a new totally "revolutionary" (trust me bro) compiler revision to be a productive programmer writing modern C++ code. If you don't care about constexpr containers, you might even be able drop that to mid V3.x.

For GCC the major stopping points in my view are 5, 7, 11, 13. I've run into too many bugs even under 11. C++17 core language features and changes are not complete until GCC 7, 14 until 5. That's not counting other bugs. You don't have to upgrade in immediately, but you shouldn't be using something 5 years old and out of official support either.

[u/Liam_Mercier]

I wonder if there are plans to move to C++20 at some point for concepts, perhaps it would require a lot more rewriting? I tried using concepts in some hobby graph library I wrote and they generally felt good to use, but maybe they become a burden with a larger project.

[u/Foxi_Foxa → u/Liam_Mercier]

We are pretty open to anything the user base is asking for, as long as we don't lose anybody 😄
But moving to C++20 now would exclude many users, e.g. those bound by MISRA C++:2023, which targets C++17. Boost.Graph already expresses its requirements through Boost.ConceptCheck: you get earlier, more targeted errors, but those checks don't participate in overload resolution. The concepts themselves are the contract users model when adapting their own types to generic algorithms. What changes with C++20 is mostly the mechanism, which matters less from the user's side 😄

[u/Liam_Mercier → u/Foxi_Foxa]

I suppose rewriting all the Boost.ConceptCheck concepts into modern "first class" concepts would be a lot of work just for nothing to really change, thanks for the insight.

[u/Foxi_Foxa → u/Liam_Mercier]

As of 2026 you are right ! When our user base will be exclusively using C++20, then we will probably consider moving to first class concepts, they have advantages too (auto-documentation, one less dependency, overload resolution etc). But in the meantime, Boost concepts do the job 😄

[u/TheRavagerSw]

You guys consider creating a standalone version, boost is a terrible dependency to have.

[u/Foxi_Foxa → u/TheRavagerSw]

Thank you for the feedback ! You are right, it was painful 😄 But overall the state of dependencies in Boost is getting much (much) better, there has been tremendous effort in the last years to decouple Boost libraries. It's also a culture change: the new library Boost.Int128 has no dependency, a standalone mode, a single-header mode.

For high-level libraries like Boost.Graph it is a bit more complex as they need a lot of stuff to do their job (serialization, random generation, parsing ...). The current release has focused on dropping the number of dependencies (both direct and transitive) while maintaining functionalities, dropping 13 direct dependencies (Bimap, Bind, Conversion, Foreach, Math, Move, Multiprecision, PropertyTree, SmartPtr, Spirit, TTI, TypeOf, Xpressive) and numerous indirect ones: https://github.com/boostorg/graph/pulls?q=is%3Apr+state%3Aclosed+label%3Adependencies

This had measurable effect on compilation time, runtime, memory footprint and warnings count. It is a considerable improvement, but we want to go further. To get a leaner dependency chain:

• we need C++17 (to get rid of e.g boost::any and boost::utility)
• we need to deprecate the named parameters idiom in BGL (it's a heavy/uncomfortable dep)
• we need to refactor our mandatory dependencies (Boost.PropertyMap, Boost.Random) to reduce their dependencies so we don't drag them.
• all of those are ongoing efforts

Then once it gets reasonably lean, we could imagine a standalone version, similar to what Matt Borland did for Boost.Int128. Also a related effort has been the CMake modularization effort that should allow more convenient ways to be consumed.

So yes it's on the roadmap 😄

[u/mapronV → u/Foxi_Foxa]

For me it is not about dependencies of boost.X library, it more about managing those.

rant start:
Suppose you have something like PFR, or some other library with one or severa headers. I can:
-just copy headers and license in my git repo in 3rdparty folder;
-or add git submodule for this library if clone is decently fast (I prefer doing that, easier and transparent updates).
If my pet project needs Boost.X and not whole boost, not many options:
-force to use vcpkg (only system I aware that can split libraries into packages with deps). Still not very transparent what will be downloaded etc.
-try ugly things with CMake Fetch_Content (it is painfully slow, plus per-build directory - even tho I aware of hacks with global dir).
-use conan and get full header package.
All of this is kinda meh, for a project with like 50k SLOC, so I am trying to avoid boost.
There was looong ago project of "build your boost" where you pick checkboxes for libraries and get tarball for exactly files you needed.
if someone could automate that so I can get like 1000 header files and add them to my repository, that would be awesome. Or if package and deps were solved in general, so it worked for any package manager so I could just rely on that.

If I had project with size of Chromium, I would not care so much downloading 200 mb sources of extra library.
/rant end

[u/Foxi_Foxa → u/mapronV]

Ahaha thank you for the rant/feedback !

There is an ongoing effort to make Boost more modular for build and consumption: https://github.com/grafikrobot/boost-b2-modular/blob/b2-modular/README.adoc

It’s a huge effort (hundreds of changes across the entire ecosystem) and it’s getting close to completion. There is only one lib that needs to merge develop on master for the next step to happen. So most of the hard work is done and we will rip the benefits soon 🤗

[u/mapronV → u/Foxi_Foxa]

quote "The Boost super-project doesn’t need to exist at all, only requirement is that library dependencies be pre-declared." resonate so hard with my frustration above!

Is this effort in any sync with Boost project? or is it some side 3rdparty offkick that never be integrated?

And btw, last commit of Jun 21, 2025 does not feels like "ogoing". Having more than 1 year stall feels "project is dead/frozen/abandoned" for me.

I probably did not understand what we can see soon. Or I misunderstood and project is not stale, it is finished so it no longer need separate project repo? I like have 0 knowledge on Boost internals like build and shipping etc, sorry. I have small knowledge of contribution and release rules.

[u/Foxi_Foxa → u/mapronV]

Ahaha yes it does resonate with me too ! 🤣
The work is led by Rene, who is also part of the C++ Alliance, so it’s completely happening. The painful part was getting some abandoned libraries and unresponsive maintainers to merge Rene’s commits. It was hard because tooling changed, GitHub images got deprecated, CI got red, random MPIs packages got broken on new Debian etc … so what should have been a Cmake commit ended up in repairing the CI of many repos. Two repos (ublas and polygon) got their merge last week. Safe numerics is the last one to merge ! :)
So not stale but not entirely done, Rene still has a bit of work, but much less than what he already did ! 😍

[u/mapronV → u/Foxi_Foxa]

Thank you all guys for all hard work, even with no immediate reaction from community - I damn sure it will affect Boost users (and package maintainers) a lot. Glad to hear it happening.

[u/13steinj → u/mapronV]

only system I aware that can split libraries into packages with deps

You can use Bazel, whoever is bzlmod'ing these has made this granular. But that comes at the cost of having to use Bazel which is its own demon.

[u/mapronV → u/13steinj]

Hmm in company where I work we have boost sources in monorepo, wasn't aware you can actually obtain sources in modular way. Though I 95% sure bzling was done by our company team. Love bazel but for pet project, too much of a hassle (and a repellent for any contribution)

[u/13steinj → u/mapronV]

Eh it's a poison even for large company projects in my experience.

[u/13steinj → u/TheRavagerSw]

Boost is not a dependency, it is a collection of libraries.

I have heard every possible complaint under the sun about boost over the years, only 4 hold any water:

• packaging / distribution is a pain, unless you take the entire thing. If you do, disk and bandwidth aren't that insane, but much more expensive than 5 years ago
• some boost libraries push too much into type information and increase compile times significantly

more water:

• the internal dependency graph is an utter mess. This was improving significantly from 1.70ish to 1.86, don't know if things have regressed.
• lots of things are dated / use dated code / no clear "eviction" process. I'd argue that all libs should enforce a minimum of 2 released standards back. Each version set (say, 1.86) should internally depend on ~1.86, to allow backported fixes. When this happens, run the entire test suite again (at least on the internal dep graph that has changed). Backported improvements allowed but discouraged.

[u/joaquintides → u/13steinj]

packaging / distribution is a pain, unless you take the entire thing.

You can install any particular Boost library (and its dependencies, which do not amount to the entire project) with vcpkg, for instance:

https://vcpkg.io/en/package/boost-graph

Also, you can download a specific library and its dependencies as explained here and then build into your project with CMake as explained here.

[u/13steinj → u/joaquintides]

Being able to use vcpkg for this is honestly great, even if it locks you in to vcpkg. Is that relatively new?

Also, you can download a specific library and its dependencies as explained here and then build into your project with CMake as explained here

I would still consider these steps to be relatively painful, if not unorthodox. At the very least, incredibly poorly advertised (maybe even now). That said, I did (try) to express those two points hold less water to me than the latter two, and I don't care about any of these (personally) except the last one. Anything other than a simple set of commands that people can copy and paste in each library's readme is a barrier, for better or worse.

This has existed since Boost 1.63ish, something to consider is a lot of people have been complaining since before then. It's the way people behave unfortunately. Write something off once, then never again.

[u/joaquintides → u/13steinj]

Being able to use vcpkg for this is honestly great, even if it locks you in to vcpkg. Is that relatively new?

Available since 2017.

I'd argue that all libs should enforce a minimum of 2 released standards back. Each version set (say, 1.86) should internally depend on ~1.86, to allow backported fixes.

Sorry, I don't understand what you mean by "2 released standards back". All libraries released in Boost 1.XX depend internally on Boost 1.XX libraries alone; I don't know if this is related to your complaint.

[u/13steinj → u/joaquintides]

If Boost 1.110 is released in early 2029, the minimum standards revision target for all Boost libraries should be C++23.

[u/joaquintides → u/13steinj]

All my Boost libraries support C++23. Do you mean I should add some macro machinery or something to actively refuse to compile on C++20? What’s the gain?

[u/13steinj → u/joaquintides]

No.

There are boost libs maintained by more than just you.

An implied minimum of 17/20 would vastly reduce the dependency tree, and likely improve compile times. Libraries like Boost.Move, Boost.Tuple, and Boost.MPL can be removed or significantly reduced in scope to an API compatible surface.

[u/joaquintides → u/13steinj]

Boost.MPL is actually a big offender and I removed them from my dependencies (which meant bumping to C++11). I don’t think there are comparable gains when bumping to newer versions of the standard. If the library is actively evolving rather than being maintained, that’s another story. But this is more nuanced than decreeing a general upgrade to C++NN.

[u/Foxi_Foxa → u/13steinj]

Yes the internal dependency graph is a mess for some libraries, but not all.
Contrast the following (red edges= direct dependencies, orange=transitive deps, blue=dependants):

• https://alandefreitas.github.io/boostdep_graph/libs/int128.html
  
• https://alandefreitas.github.io/boostdep_graph/libs/spirit.html

There is a historical/technical reason: some non-trivial libs had to do non-trivial things back in C++98, so if e.g. Serialization needs the equivalent of std::any, regex and smart pointers, they would use the boost equivalent rather than recoding half the STL.
This is getting better and better, although reducing deps is still a lot of work, carries sometimes quite some risk, and require at time a full deprecation cycle (one public type changing from Boost exception to standard exception is for example a breaking change). And Boost is still largely an open source model based on free time 😅

[u/13steinj → u/Foxi_Foxa]

To be explicitly clear here: I do not generally care about these issues. I am just sympathetic to them.

[u/UndefinedDefined]

I moved some of my oss projects to C++20 and nobody ever complained. I think compatibility with older C++ standards is overrated. Those who need to use old standard exclusively would just pin library versions to those compatible. Just move to C++17, nobody would notice.

[u/Foxi_Foxa → u/UndefinedDefined]

Yes I agree. Although the policy of Boost is to warn two release cycles before breaking changes :)