C++ standards

[dabbertorres]

Oof, guess I'm blind. Thanks.

[Gleade]

- take latest versions supported by the main compilers you work with, only considering their very latest version. You're talking about future so it's not the time to even consider non-latest compilers. And deduce standard C++ you case use from that
- don't ask yourself if you need latest usable standard, just use it, you don't want to spend again time to decide whether standard should be upgraded if you could have done it 3 years earlier for the same price

I'm not sure if this is directed generally at everyone participating in the discussion or directed at SFML's development. SFML isn't just a tool we use. There's no company or one entity behind SFML that would define what is required or not, instead we're dependent on the community and there are some who would be left behind if we just ignored C++ standards.

Sure, the argument can also be made the other way around, that not moving forward with the standard just means we're push other people away. But if that's the case, then that's their decision. Everyone can use SFML, whether you use a new standard or not, it's up to you to decide if it's a game breaker that the library doesn't use modern C++ internally. Where as if we just picked C++17, because I'm using it right now, many won't even be able to compile SFML anymore and it would not be their decision.

If you're just a consumer of libraries and C++ in order to build end user applications, then sure, just go with it, as long as your team/business allows it, but once you write code for others, you can't just ignore their requirements.

I'm quoting this entire post to give my post context.

Where as if we just picked C++17, because I'm using it right now, many won't even be able to compile SFML anymore and it would not be their decision.

Who is "many"? Have there been surveys to reflect who is using what standard/compiler? I'd be curious to know how many users of SFML are using legacy hardware/compilers.
Also; wouldn't using a compiler not up-to-date be a choice in the 99% of cases?

I think a decision shouldn't be based on assumptions.

But in our case, we really need to modernize the code base. The main advantage is easier maintenance, and consistency with new code (which will be written using modern C++). Writing unit tests first (which is what we're doing) will help there, to ensure no regression while rewriting the code.

This to me is the perfect answer.

[markand]

My $0.02, I think C++17 is the way to go. SFML 3 is not about to be released anytime soon and we're almost in 2020.

C++17 is even available in Visual Studio, Android and in major distributions. I think there is no good reasons to stick with C++11 or C++14.

Major features that C++17 offers:

• destructured bindings (utterly convenient to do const auto [x, y] = getPosition())
• std::variant
• std::optional
• std::string_view
• if / switch initializers

[Nexus]

What I wrote almost 2 years ago:

When choosing a standard, we need to decide:

• Who are we targeting? Does our main user base have access to recent compilers?
• What newer C++ features can SFML directly benefit from?
• When would SFML 3 emerge?

The last point is important. If we were to choose C++14 at this very moment, it's already "outdated" by 4 years. Add to that the time until SFML 3 is ready.

And SFML 3 is still nowhere. So I'm no longer sure if this should be the criterion.

Would we even require a major version to add more modern C++ features?
A new C++ version is a breaking change only w.r.t. old compilers, it's not breaking client code. Intuitively, it appears to me that a typical SFML user has access to an at most 3 years old compiler (to support C++17).

My suggestion:

• Start from C++17 -- it's old enough to have decent compiler support but also has helpful stdlib additions
• Include support from SFML 2.6 or (depending on time to implement) 2.7
• Use features mainly to add nicer APIs (move ctors, conversion from std::chrono/std::filesystem/...) and simplify internal implementations (lambdas, unique pointers)

SFML 2.6/2.7 could then be seen as a "proof-of-concept" of more modern features, and maybe based on that, we learn how to improve APIs for SFML 3.

[eXpl0it3r]

Given the time frame C++17 is what we're aiming for already, but with SFML 3.
Refactoring code without breaking API/staying SFML 2 compatible is an unnecessary burden.

I suggest you take a look at the currently planned Roadmap: https://en.sfml-dev.org/forums/index.php?topic=24372.0

[Nexus]

Thanks for the link, I missed that latest update. SFML 3 planned directly after 2.6 changes things of course.

I've added some more concrete suggestions (so far mostly on the C++ side) directly in the other thread.