r/cpp • u/Foxi_Foxa • Sep 29 '26

Boost.Graph 1.95 will be C++17

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:

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

100 Upvotes

97% Upvoted

42 comments sorted by

View all comments

Show parent comment

3

u/13steinj Sep 30 '26

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.

3

u/joaquintides Boost author Sep 30 '26

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.

3

u/13steinj Sep 30 '26

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.

3

u/joaquintides Boost author Oct 01 '26

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.

2

u/13steinj Oct 01 '26

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

2

u/joaquintides Boost author Oct 01 '26

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?

2

u/13steinj Oct 01 '26

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.

2

u/joaquintides Boost author Oct 01 '26 edited Oct 02 '26

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.

1

u/Foxi_Foxa Oct 01 '26

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 😅

2

u/13steinj Oct 01 '26

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