C++14!

[Gobbles]

Thought I'd toss a link in here for everyone to see:
https://isocpp.org/blog/2014/08/we-have-cpp14

Exciting stuff, I'm interested to see if any of the new features will be making it into SFML 3.

Quick Edit: Thought I'd add this wikipedia page which has the New Features nicely summed up
https://en.wikipedia.org/wiki/C%2B%2B14#New_language_features

[georger]

Thought I'd toss a link in here for everyone to see:
https://isocpp.org/blog/2014/08/we-have-cpp14

Exciting stuff, I'm interested to see if any of the new features will be making it into SFML 3.

Hmm, the C++11 spec was completed 3 years ago and AFAIK only clang is 100% compliant with it... If that's any indication, I think it will take quite a while before all the major compilers (GCC, Visual Studio, clang) implement C++14 in any substantial form.

I'm not part of the SFML team and can't speak for them, but in order to support "older" compilers (VS2012, I'm looking at you), using C++14 is not yet an option. Parts of C++11, maybe.

[eXpl0it3r]

As mentioned due to compiler support, we can't just go ahead and use the latest and greatest new features. The moved towards non-optional C++11 usage in SFML 3 is already a slightly risky move, since it will "ban" older compilers such as VS 2010 or GCC <= 4.7.x.

But nothing has been written in stone (not even how far C++11 usage goes), thus if SFML 3 is very far in future (let's hope not!) we might look at C++14 again.

Looking at the current feature list however, there isn't really anything that would be highly interesting for SFML itself, the features are rather some highlevel additions to sone C++11 bits.

[Ixrec]

There was much discussion about conditional C++11 support in the past: https://github.com/SFML/SFML/issues/129

I believe the reason nothing ever got implemented is because the biggest benefits one would get from switching to C++11 all involve significant rewrites and becoming incompatible with C++03 (unless you want to support two code bases, which nobody does).  Some quotes from the related thread which explain this more:

From a development point of view, I think people underestimate the amount of maintenance that would be required to have conditional C++11 support, i.e. separate builds for C++03 and C++11 which is the only feasible way to provide such support.

Either really ugly boilerplate macros would have to be inserted all over the place which would make reading and modifying the files a pain (go try to read through some boost headers that support multiple language variants) or the codebase would have to be split into a C++03 and C++11 implementation, which would mean a lot of code duplication and possibly having to modify multiple files to fix even trivial bugs.

It should also be noted that while some C++11 features provide additional optimizations or convenience for those who use it, others have a deeper influence on the design of the library. When providing only conditional C++11 support, then:
sf::Thread, sf::Mutex, sf::Lock and sf::ThreadLocal cannot be removed in favor of their standard counterparts
There will be further API restrictions, e.g. it's not possible to store non-copyable objects in STL containers or to return them from functions, and we need the namespace idiom to scope enumerations
A refactoring and simplification of several internal parts, especially regarding resource and thread management, will be prevented due to the lack of thread_local, std::unique_ptr, std::thread, std::mutex, std::atomic.
The price to pay for conditional support is, besides the points mentioned by binary1248, an unnecessarily big API and a more complex and potentially less robust/portable implementation.

I assume C++11 and/or 14 will happen for SFML 3 solely because by the time work actually starts on it (which we know will be a very long time), there probably won't be any reasons left to care about C++03 compatibility.

[Tank]

Yes, C++11 will definitely break API compatibility, so it's targeted for 3.x.

[Jesper Juhl]

Hmm, the C++11 spec was completed 3 years ago and AFAIK only clang is 100% compliant with it... If that's any indication, I think it will take quite a while before all the major compilers (GCC, Visual Studio, clang) implement C++14 in any substantial form.

As far as I know, GCC 4.8.x is also C++11 feature complete.

[FRex]

As far as I know, GCC 4.8.x is also C++11 feature complete.

It's not. Some (more or less obscure) things are still missing.

[Strelok]

https://gcc.gnu.org/projects/cxx0x.html
https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.200x

[Jesper Juhl]

OK. Fair enough. Details are missing. But it's largely complete ;-) for most intents and purposes. :-)