Improved Iterator Support for sf::String

[massive_potato]

Would it be possible to implement more support for iterators (as in find, insert, construction, etc.). Additionally, would it be possible to get support for reverse iterators? I looked on the forums and could not find anything about this, so I was wondering if it was already planned or if it would ever be implemented.

[Laurent]

I'm not a big fan of reimplementing a complete string class. However there's no other solution yet, that's why sf::String exists. But before making it the ultimate string class, I need to make sure that it is really needed, and that I can't find a more clever solution.

[massive_potato]

Thanks for the quick response! I guess that there are work-arounds for all of these things, so I'll just use those. Thanks again!

[Oberon]

Why was sf::String introduced in the first place instead of directly using the internal std::basic_string<Uint32> plus maybe a few additional sf::Utf helper functions for converting whole strings to/from ANSI? If I think of it, I don't see any real benefit in the class.

[Laurent]

Convenience and automatic conversions.

Users prefer to write this:

sf::Text text("hello");

Rather than this

std::basic_string<sf::Uint32> str;
const char* hello = "hello";
sf::Utf32::fromAnsi(hello, hello + strlen(hello), std::back_inserter(str));
sf::Text text(str);

A compromise would be to wrap this code into higher-level functions:

sf::Text text(sf::ansiToUtf32("hello"));

But one still has to know both the source and target encodings, whereas it is all automatic with the current API.

[Oberon]

One has to know the encodings anyway: If you initialize a string with

sf::Text text("hello");

then "hello" has to have the current global locale's encoding. It can't e.g. be encoded in UTF-8 when the locale's encoding is Latin 1  [of course "hello" can, but strings containing special characters probably can't].

But if implicit conversion is desired, sf::String could be used just for this: In function parameters and return values. The library and users are then free to store and use the data as either std::basic_string<Uint32>, std::string or any other type to which a conversion exists.  All that's missing is a convenience

typedef std::basic_string<sf::Uint32> sf::Utf32String

and

sf::String::operator  sf::Utf32String() const;

. Then no one has to bother performing string operations on sf::String but can use the full power of std::basic_string -- without API incompatibilities.

[Laurent]

This would make things more confusing: you end up with two string types. And one even has different naming conventions than other SFML classes (because it's just a typedef of a STL class).

[Nexus]

For future design choices in the Unicode API, you should also consider new C++ features. C++11 introduced the new types char16_t and char32_t to store UTF-16 and UTF-32 characters. There are new string literals as well as classes std::u16string and std::u32string, which instantiate the std::basic_string class template.

[Laurent]

You should rather post that in the "C++11 support" task on the tracker

[Nexus]

It is already there, and guess who wrote it... You

[Laurent]