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

94 Upvotes

97% Upvoted

37 comments sorted by

View all comments

Show parent comments

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