C++ standards

[Ceylo]

Sorry I was not very clear in my previous post but you're right. When saying "take latest versions supported by the main compilers you work with" I actually meant "take latest versions supported by the main compilers you and your users work with".

I guess this addresses your comment

Edit: implicitly this also means that if you user use a compiler version that don't support the standard you'd like to use, but the latest version of that compiler does, just ask them to update their compiler.

[eXpl0it3r]

Edit: implicitly this also means that if you user use a compiler version that don't support the standard you'd like to use, but the latest version of that compiler does, just ask them to update their compiler.

If it were always that easy, nobody would be using legacy-anything. "Just update" is not always a viable solution unfortunately, which is why we want to make a clean cut at one point (version 2.x is C++03, version 3.x is C++1Y).

[Klaim]

Here is my current opinion, considering SFML:
Go with C+17.

Aguments:

 - std::filesystem : if SFML relies on it by default (or not use filesystem at all and let the user feed SFML), the codebase would be reduced;
 - std::string_view: There are several (not all) interfaces of SFML that take std::string while std::string_view would be a far better default. Notably the API for passing shader scripts (which imply a lot of copies). I pointed this issue before but the (reasonable) answer was that adding a string-ref type would be another thing to maintain, and there is no SFML dependency providing one. With C++17 std::string_view would do the job.
 - std::any and std::optional might be very helpful in several SFML APIs evolutions.
 - it's completely implemented by major compilers (I think there might be holes that SFML will not use anyway);
 - if the next release of SFML happen around the end of the year or next year, there will be about a year before the following standard is ratified (and a lot of it's stabilized features are already implemented in at least 2 compilers);
 - backward compatibility should be good enough to not force users to change their code (except for changing APIs);
 - it's the simplest way to open the possibility of reducing drastically codebase size (less code, less bugs - most of the time) (I'm htinkin both C++14 and C++17 here);
 - changing the C++ version do not mean that all the code have to be upgraded immediately or ever, but it makes it possible and easy to check;


I was wondering: what are the arguments against going directly to the current standard? It's not really clear from the current discussions.

[Nexus]

Klaim brings up some really good points.

C++14 was a small addition, at least compared to C++11 -- I saw it mainly as attempt to make features introduced in C++11 more complete and consistent. There were not many library additions, mostly smoothing the corners of language features.

C++17 is different, with std::optional, std::filesystem and std::string_view as probably most impactful library features. While the latter is mainly an optimization, optionals allow APIs to be more expressive, and avoid workarounds like the return-bool-and-output-parameter idiom.

By the way, I found a nice overview over different standards' features.

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. "Outdated" in quotes because C++14 does not expire, it has however been superseded by more recent versions.

[Rosme]

About the recent compiler thing, according to this page which is quite up to date, C++17 is pretty much supported by every major compiler that most people uses (MSVC, GCC, Clang). So going the C++17 way for a version that will probably be out in two or three years at least seems like a normal choice. Even if SFML 3 would come out today it would makes sense.

There was a time where it was somewhat recurent(at least in IRC) for people to ask why doesn't SFML support filesystems. That kind of question can easily be solved with C++17 by using std::filesystem. There was a time where SFML was considered more modern than SDL for using hardware acceleration. If we don't go with a recent well supported standard, well SFML is not exactly modern anymore. Just my 2cents for supporting C++17.

[Elias Daler]

I'm not sure C++17 will bring much positives to SFML. Are there many C++17 libraries out there which are not super-complex and/or template-heavy?

Unless there are strong examples of using std::optional, std::any and other stuff to make SFML's API better, I don't see why C++17 will be really useful.

[dabbertorres]

I imagine constexpr-if could be useful for platform specific code.

I know I'd find std::string_view and std::filesystem useful as well.

[Laurent]

Everyone talks about std::filesystem but it would be an internal detail, end users wouldn't see any difference. And anyone can already use std::filesystem or anything from C++17 in its own code with a C++03 SFML right now, of course.

std::string_view, how would it deal with sf::String?

And I don't think it's about C++17 or not, it's more about the features that we need. Compilers usually implement stuff gradually anyway, they don't suddenly get all the new C++17 stuff right after the standard is officially out. Some features are well supported very soon, even before they get validated, some others take more time.

[Elias Daler]

Yeah, as far as I know there's no std::filesystem on the latest XCode on Mac OS X... imagine that.

I imagine constexpr-if could be useful for platform specific code.

Not really. SFML has it neatly separated into different impl cpp files. And #ifdefs are still ok for platform specific stuff.

std::string_view has so many gotchas, that I've been staying away from it, but maybe I just had a bad experience.

Even if all current compilers support C++17 well (and MSVC, Clang and GCC do), you still need to remember about iOS and Android which usually lag in terms of compilers... And some distros don't have latest GCC/Clang in them, so you get 100% C++14, but 50% C++17. I think this will still be the case for the next 3-5 years.

[dabbertorres]

Everyone talks about std::filesystem but it would be an internal detail, end users wouldn't see any difference. And anyone can already use std::filesystem or anything from C++17 in its own code with a C++03 SFML right now, of course.

True.

std::string_view, how would it deal with sf::String?

Not directly with sf::String. One, although not very important (minor optimization, maybe), place it could be useful would be with sf::Shader::setUniform, which is using const std::string&.

And I don't think it's about C++17 or not, it's more about the features that we need.

Agreed! Plus, if desired, I know CMake has ways of specifying required language/library features which could be useful for identifying supported compilers and whatnot, based on a defined feature-set.

I imagine constexpr-if could be useful for platform specific code.

Not really. SFML has it neatly separated into different impl cpp files. And #ifdefs are still ok for platform specific stuff.

True!

Yeah, as far as I know there's no std::filesystem on the latest XCode on Mac OS X... imagine that.

Oof. I keep hearing things that make me glad I don't have to work that, haha.

[barnack]

it's more about the features that we need.

That's a good point about something i noticed eXpl0it3r wrote: "Code simplification: smart pointers".
Do we really need that?
I might not be an expert about programming, but if the existing codebase is working internally with good old pointers AND without memory leak issues (i'm supposing it does), which means dynamic memory is properly managed, then what's the point of replacing them with smart pointers?
In my point of view smart pointers can help to make quick code, can allow the programmer to be more lazy, but they take this small amount of resources more than normal pointers to, which in the case of an already robust code seems just a waste to me.
Am i missing something?

Sorry for the bad english, i've been awake since more than 48 hours 

[Laurent]

I might not be an expert about programming, but if the existing codebase is working internally with good old pointers AND without memory leak issues (i'm supposing it does), which means dynamic memory is properly managed, then what's the point of replacing them with smart pointers?

This is often a valid point. 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.

In my point of view smart pointers can help to make quick code, can allow the programmer to be more lazy,

No. The point of these utility classes is to write safer code.

but they take this small amount of resources

They don't. They can even be lighter than the code you would have to write without them.

[Elias Daler]

In my point of view smart pointers can help to make quick code, can allow the programmer to be more lazy,

No. The point of these utility classes is to write safer code.

And not just safer, but also smaller. and easier to read. Destructors are rarely written, same with "cleanup" sections of functions, catching of exceptions to clean up the stuff that was previously allocated, and so on.

[dabbertorres]

Writing unit tests first (which is what we're doing)

Is this on GitHub? I don't see a branch or anything that looks like it at a glance (In the interest of helping, if possible).

[eXpl0it3r]

Is this on GitHub? I don't see a branch or anything that looks like it at a glance (In the interest of helping, if possible).

You don't have to look far.

https://en.sfml-dev.org/forums/index.php?topic=16184.0
https://github.com/SFML/SFML/commits/feature/unittest
https://github.com/SFML/SFML/pull/1475