sf::ThreadLocal => no need if sf::Threads become a std::thread ? (not sure what it does)
Not std::thread, but the thread_local keyword
Not sure to understand...are you talking about
http://en.cppreference.com/w/cpp/language/storage_durationsf::InputStream => std::istream (literally the same)
If it were literally the same, SFML had used std::istream in the first place, as it's no C++11 feature. Read the documentation to see what it does.
I should not have said (literally the same) on this one, but the fact is that you are using it as the base class for all your input with a focus on file input
Abstract class for custom file input streams.
This class allows users to define their own file input sources from which SFML can load resources.
By replacing this with
std::istream we would have access to all of the standard library type that inherit from
std::istream and the future type coming (C++17, C++20,...) like in C++20 there's the standard networking library that should be ready and if it magicaly have a
std::isocketstream we could have without change support for loading assets from a network... (this is a crude and simple exemple, but serve it purpose).
My stand is it would be better to use as much standard library as possible, because it's standard behavior across all platform, there's more chance end user will be able to use new language feature without major change to SFML or a ton of wrapper and finally because if we use the standard library people will have less stuff to learn to start using SFML, because they should understand the base of the Standard Library, and while learning to use SFML they will learn stuff they will be able to reuse outside of SFML.
And for the low level stuff.... well welcom to C++
![Wink ;)](https://www.sfml-dev.org/forums/Smileys/default/wink.gif)
and let's just make even more awesome tutorial for SFML 3 that will make it easy to learn that stuff and combined with the current style of the Documentation (with exemples) (seriously SFML Tutorials and Documentation Rocks!!!).
Also, some implementations, while they exist in the standard library, are rather low-level and not always well-supported by all compilers (e.g. it took quite long until high_resolution_clock was adopted by MSVC). This is also a point to consider when changing the implementation.
I'm not following you on this one.... there was multiple intervention on this forum thread about SFML 3 using C++11, and all my implementation replacement use at most C++11 and on top of that all major compiler vendor (GCC, Clang, MSVC) now have stable support up to C++14 language features
http://en.cppreference.com/w/cpp/compiler_support we're nearly in 2017.... C++17 is nearly here... C++11 use should not even be in debat right now