I think I'm posting in appropriate place, please move it if I'm wrong.As we all (?) know, SFML (I'm talking about version 1.6 here) uses standard C++ locales in some places. And we all (
) know that libstdc++ (the standard C++ library that comes by default with GCC) is inherently broken, because its support for locales is virtually nonexistent on Windows (Cygwin does not count). So, SFML has some workarounds here and there just because of that.
The problem lies in checking if we have a working locales - it's done by checking whether __MINGW32__ (I'm not sure how this macro is called) exists, and if it does, then the library assumes that locales are broken.
This approach seemed to work just fine hitherto. However, the idyllic world shattered when I tried to compile SFML with STLPort as a standard C++ library, rather than the default libstdc++. Of course, SFML thought that I don't have working locales and workarounds were compiled instead. I
do have working locales, why not use them?
My question is: can SFML check the standard library itself instead of relying on just a compiler check in order to test for locales? Of course, it is certainly possible for a user to modify these checks manually (or simply delete them), but it's not very convenient solution, as it has to be done for each new version of the library.
Yours faithfully,
Silvah.