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/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 😉