wstring

[xDarkDelux]

You use std::string as the main text type, do you plan to add the possibility of a global config in the future, which will give the ability to use wstring/wchar_t globally instead of std::string?

[mikke89]

Thanks for the suggestion, I understand this would make library interaction simpler when you're already using wstring. However, this one I can say will not be added. It opens up more questions, should we support both 16 and 32 bit wchar_t? If so, which encodings should they be considered to be? Probably UTF-16 and UTF-32. But now we have to add support for those encodings as well, and test it all. It's really a lot of work that can be better spent elsewhere, for little gain.

Instead, you'll have to do this conversion at the API boundary.

[xDarkDelux]

I think UTF-16 would be enough, at the expense of 16-32 bits - I'm not competent here. For example, I have a project built using wchar_t as the main text type, that if I need to output a localized string in Cyrillic, I need to call ConvertToUTF16 from your api every time for this, and at this point I'm worried about performance, if necessary do each tick in some place - this raises even more doubts about the need for such a transformation every time ... and if, for example, I myself redo everything in your project to wstring - then there will be a problem with updating :)

[mikke89]

To me, this sounds like a case of premature optimization. I'm pretty sure the performance implication is negligible, unless you're pumping huge walls of text every frame. And in that case you will have larger performance issues elsewhere. At the very least, that should be the assumption unless you have measured otherwise.

Generally, instead I'd encourage you to consider changing to std::string internally, see: http://utf8everywhere.org/

[xDarkDelux]

thanks for the info and sorry for wasting time)

[mikke89]

No worries, questions and suggestions are always welcome.