std::basic_string crash about sfml HOT 10 CLOSED

Finally got an answer from some Apple dev. They apparently don't want to fix this issue on their side. They gave me three workarounds :

• Use extern template class std::basic_string<int>; in String.cpp and add template class std::basic_string<int>; in ALL C++ source that uses sf::String. Clearly not feasible, of course.
• Use clang with its new std lib ( -stdlib=libc++ compiler option ). This is available only on Mac OS X 10.7+ thus this is not suitable for SFML.
• Use std::vector instead of std::basic_string and manually manage trailing \0.

The last solution is the better but still I don't like it : modifying a part of SFML that work on other OSes to make it work on Mac is not a solution.

From this perspective I guess the above workaround with _GLIBCXX_FULLY_DYNAMIC_STRING macro is the only solution that I know of at this moment.

from sfml.

Out of curiosity, why would the first option not be feasible? template class std::basic_string<int>; could just be put in String.hpp, could it not?

from sfml.

Good question. I didn't remember so I did the modification to test. Here is the diff.

The problem is, apparently, it creates duplicate symbols with predefined templates.

from sfml.

I didn't compile SFML from source, and I wanted a different way to size text in any case. The easiest thing for me was to create an sf::Text alternative myself, copying from Text.hpp and Text.cpp and using something other than sf::String.

from sfml.

using something other than sf::String.

but you know that this issue is directly related to the underlying std::basic_string, right?

from sfml.

Of course it's not nice to keep things around that can possible crash an application, but I wonder whether it's a library's job to implement workarounds for broken STL implementations, especially if it's only for a specific and older version.

On the other hand if it's just a simple version check and flag setting in CMake, I don't see a reason not to implement it and reading a bit more (e.g. here) about that flag it seems common practice to do so.

The question is of course, whether there's still someone around with that old system setup who can test a possible implemented fix. . 😉

from sfml.

Marco plans to drop support for OS X 10.5 and 10.6 in a near future. I guess that will solve this problem.

from sfml.

Unfortunately, it is still present on 10.7/8 since gcc is still available on those OSes. But I guess implementing the fix as @eXpl0it3r suggested should not harm anyone.

from sfml.

But GCC has been removed since Xcode 4.2...

from sfml.

Right! They replaced it with llvm-gcc. So it should be safe to close this issue now without a fix.

from sfml.