0

I'm maintaining a library written in C++, which offers modern-C++ bindings for another API that's C-ish (it's this one, although I'm trying to make this question somewhat more general).

Now, when I started working on this library, it was 2017. The newest published standard version was 2014, and 2011 was already popular, but not ubiquitous. I've stuck to requiring only C++11 and nothing above that, so far.

Now we're in 2023. The published standard is 2020, and C++2023 is feature-complete. I'm wondering - is it time for me to increase the minimum supported C++ language version? Naturally, this will let me simplify my API somewhat, and possibly forego bundling some code which has, since 2011, made it into the standard library (depending on whether I switch to C++14 or C++17 or even C++20).

Of course, the obvious detriment is that people using older versions of C++ will no longer be able to use my library. But - I have no idea how many; nor whether they'd be able to compensate somehow (e.g. downloading and building a newer compiler, upgrading their OS distribution etc).

So, my question to you: What considerations would you take into account when making such a decision? And - how would you try and estimate the incompatibility implications of this move?

PS - Assume the library's API is allowed to change with increasing versions.

5
  • 3
    "I have no idea how many" - here is your problem. Solve that. Try to come in contact with your libraries users. Try to find out which C++ standard they are using.
    – Doc Brown
    Commented Mar 12, 2023 at 18:38
  • @DocBrown: Ok, that's an idea, but - that doesn't seem very possible; only Microsoft spies on the people downloading from GitHub servers, I don't... :-(
    – einpoklum
    Commented Mar 12, 2023 at 19:06
  • 3
    Don't ask us. Ask your contributors and folks who log bugs. Write down the current Project Goals, including C++11 support. And then propose a modified set of goals and see how folks respond. Do a feature freeze and write down what kind of bugs (security ones?) will still be fixed. Then start using C++20 under new names so you don't break old stuff. Also, package for Debian so you get PopCon stats (popularity contest, download figures). Think of it as an '11 project dies while a '20 is born.
    – J_H
    Commented Mar 12, 2023 at 19:56
  • 2
    @einpoklum: you don't have to spy on them - make an announcement about your plans at your Github site and ask for feedback at the discussion site.
    – Doc Brown
    Commented Mar 12, 2023 at 20:36
  • 1
    @DocBrown: You mean, announce I'm thinking of upping the standard version... hmm. Interesting idea... yes, I guess that will give me some idea of what people think, even if it's incomplete coverage.
    – einpoklum
    Commented Mar 13, 2023 at 8:06

1 Answer 1

1

Although you only ask in relation to a library, I will answer for both a library and an application and the considerations are slightly different.

In general, you should not update to a newer version of something until the benefits outweigh the costs.

In both cases, the benefit of switching to a new(er) version of the C++ standard is that you can make use of the features that were added to the language. As the C++ standardization effort is very much focused on maintaining backward compatibility, you don't really have to worry about features being removed.

Application

In application development, the costs associated with using a newer version of C++ center around the required tooling update and the familiarity of the developers with the new features.

If you do, or can introduce, regular compiler updates, then that cost is just part of the regular development costs.

What then remains is the familiarity with the new features. The developers will have to invest some time to know what features have been added, how those features work and how they can help them. But that doesn't have to be a big-bang cost. You can just gradually allow the use of new features.

Libraries

For libraries, the same costs apply as for applications, but there are some additional cost factors to consider in the form of your users.

Your user base may not be able to update their toolchain as easily as you can do it, especially if you also have users from a regulated industry (automotive, healthcare, etc.).

Also, if features from the new C++ standard make it into your API, then you have to consider how much of a learning curve it will be to use your new API.

If you don't know who your user-base exactly is, reach out to them. Make a very public announcement that you are planning to drop support for older C++ versions and invite everyone to respond to that plan.

In general, for libraries I try to keep the minimum required C++ version as low as possible to support as many users as possible.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.