C++ standards

[Mario]

Shouldn't be a problem, I think it just needs some adjustment (or potentially a switch to Clang). Haven't tried it though, but it should be supported.

[Hiura]

But in case of simple structs and classes, which have none of these, there's no need to do this because everything gets generated always.

PODs are indeed a different thing and therefore need different rules.

Anyway, this is more or less a detail -- as long as the rational is properly documented in the Code Style Guide it's not a significant problem for us in practice I think.

[DeathRay2K]

And just food for a (thought) experiment: If we had a mechanical way to transform SFML into a header-only library, sure it will take a fair bit longer to build your application, but I can guarantee you that it will also run faster than it does "linking the traditional way".

I know this is a bit tangential to the topic, but this would be fantastic.

On Rule of Five vs Zero, I think Zero when possible makes it more clear. That way, if in future you do need to change from one to the other, you won't forget to implement or remove any methods,.

[Nexus]

I'd definitely vote for the Rule of Zero. I'm a big advocate of reducing unneeded boilerplate code, I even went as far as writing a smart pointer for deep copies, to avoid the hassle of writing the Big Three/Five.

I would not use auto where it doesn't clearly help the readability of code (mostly iterator declarations and lambda expressions). Removing types from code can decrease expressivity and require additional lookups to understand a code's context. I also wouldn't use the trailing or inferred return type unless dealing with heavy template code.

[Turbine]

Could you consider also using r-value moving, using "Type&& val" and "std::move()".

It'd sure save a lot of useless copying for position/proportion/string constructors and setters.

[Nexus]

Move semantics will definitely be used, as already the lowest C++ standard being discussed (C++11) supports them.

For positions (or other value types that store all the data in the object itself) they don't make sense however.

[eigenbom]

I highly agree with updating the c++ version. Some thoughts:

• c++ core guidelines may be useful when deciding how to restructure some of the api
• clang-tidy/clang-format could help with upgrading the code (though clang-tidy has some flaws)
• enum classes should be used if possible

Don't want to bikeshed, but I'll just to say that less use of auto is better. e.g. the auto here makes the code a little harder to follow:

auto bounds = sprite.getLocalBounds();
rectf bounds = sprite.getLocalBounds();

[MorleyDev]

I'd actually argue that the problem there isn't auto, it's that using auto reveals "getLocalBounds" isn't sufficiently named and instead should be something like:

auto bounds = sprite.getLocalBoundingRect();

But I'm a "type deduce all of the things" type of developer. I use var almost exclusively in C#, and tend to favour the approach closer to functional languages where you let the compiler figure out at much as possible. Types are just the contracts of the code, and only exist to catch contract violations at compile time and to work with the names of things to provide self-fulfilling documentation for those contracts.

However, C++ being a recent addition to the world of type deduction, I'd understand if the SFML team were skittish about committing whole to it to such a degree.

[Laurent]

The use of "auto" to deduce a variable type happens either in your own code or in SFML internal code. So how what we'll decide would change the users life in any way?

[MorleyDev]

I was merely weighing in with a counter-point to the "being explicit improves readability" argument, namely that the fault could be said to lie in the functions name, and auto helps avoid being overly explicit and capturing what is actually meant, the type information being largely tangential or even a distraction to the user outside of documenting and capturing contract violations.

My last comment, that I understand why the SFML team would avoid doing so, was also not meant as in "not doing so would negatively impact me", but as in auto is relatively new to C++, and keeping closer to a style other long-standing C++ developers would be more familiar with, thereby not putting off developers from submitting pull requests for outstanding issues due to the code being 'too different from what they are used to', may be considered a reason to avoid heavy use of auto in and of itself.

Sorry that wasn't clear.

[Laurent]

My reply wasn't targetted specifically at you, it was just a general comment to the discussion about "auto"

[MorleyDev]

My reply wasn't targetted specifically at you, it was just a general comment to the discussion about "auto"

My apologies, jumped the gun a bit there I'm afraid. Whilst auto as a whole doesn't affect the end user, it is one of those things developers love to get worked up about isn't it? Though the adoption of such things does raise a question as to whether adopting them risks putting off the 'old guard' of C++ developers (though I imagine auto would actually feel very familiar to developers used to most of the not-Java-or-pre-C++11-languages).

Actually, that is a thought I think I may have stumbled on in my needless clarification. A lot of the examples I see coming out of the C++ committee members of late seem to use auto fairly regularly, though that may be a selection bias on my part. This makes me wonder if the C++ committee are attempting or hoping to take C++ into an 'auto-first' mindset.

And if that is the case, that poses the question of whether SFML should follow suit. And likewise if that is not the case, I am experiencing selection bias and as a whole the C++ committee members are fairly auto-light or auto-middling, that poses the same question as to whether SFML should again follow suit and adopt their approach.

That then goes into should SFML seek to follow the lead of the C++ committee members in general or not in terms of code style (snake_case aside because....just...just because).

[jamesL]

read this today which I thought had some nice examples

From C++ 11 to C++ 17: A Walkthrough

https://www.codeproject.com/Articles/1221623/From-Cplusplus-to-Cplusplus-A-Walkthrough

[Ceylo]

This is funny to see here more or less the same discussion that we had at my workplace

What I'd recommend:
- 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
- don't bother defining too many rules, you'll see over time how it feels, just try to keep code simple and be smart. So for example you don't need to define when auto should or shouldn't be used because: either way it doesn't make such a big difference in most cases so wearing your keyboard out isn't worth it , and whether it's appropriate really depends on contexts that you can't possibly all predict now

[eXpl0it3r]

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