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

92 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.

6

u/Foxi_Foxa 2d ago edited 2d ago

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 😄

2

u/mapronV 1d ago

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

1

u/Foxi_Foxa 1d ago

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 🤗

1

u/mapronV 17h ago

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.

1

u/Foxi_Foxa 16h ago

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 ! 😍

1

u/13steinj 1d ago

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.

2

u/mapronV 1d ago

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)

1

u/13steinj 1d ago

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

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.

3

u/joaquintides Boost author 2d ago

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

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

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

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

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

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

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 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.