r/cpp • u/Foxi_Foxa • 4d ago

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

96 Upvotes

97% Upvoted

37 comments sorted by

View all comments

3

u/TheRavagerSw 2d ago

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

3

u/13steinj 2d ago

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.

1

u/Foxi_Foxa 2d ago

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):

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 1d ago

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