Changed all core::unicode::ustring to std::u32string #13775
Conversation
|
Thanks for the contribution. However I was under the impression that we used the custom container implementation because wstring can be UTF-16 or 32 and we require to iterate each codepoint. |
|
If that's the case, core::unicode::ustring is a bad container for that purpose since it is always UTF-16. A better container is std::u32string. It is my mistake, I thought that Windows was compiling with MinGW which makes wstring UTF-32. I will update the code to use std::u32string. |
|
Made the change! |
We primarily use MinGW, which however still has a 2 byte-sized wchar_t. Even if not we should generally be portable in this regard. |
|
Thanks for correcting me, and it should be portable now. |
calebabutler
force-pushed
the
change-core-ustring-to-std-wstring
branch
from
b8db343
to
0518507
Compare
I changed all the instances of core::unicode::ustring to std::wstring. This was not too hard as this data structure is only used in two files. Since IrrlichtMT does not use core::unicode::ustring anywhere except the header in which it is defined (or anything else defined in that header), we will be able to remove the include/irrUString.h file from the IrrlichtMT repository, removing the last non-STL container from IrrlichtMT.
Since the Windows build uses UTF-16 for the std::wstring type, I replaced std::wstring with std::u32string to make the code behave the same across platforms. Now, in all cases, u32strings are UTF-32, and the code operates only on valid code points.
calebabutler
force-pushed
the
change-core-ustring-to-std-wstring
branch
from
0518507
to
1d867e1
Compare
sfan5
added
Action / change needed
sfan5
changed the title
sfan5
removed
the
Action / change needed
There was a problem hiding this comment.
Tested on linux. Colors and translations still seem to work.
<codevct>, std::codecvt_utf8_utf16 (but not stc::codecvt), and std::wstring_convert are deprecated in C++17. But I guess we can change that later.
I'm not entirely sure if the io::path conversions are correct.
I tried setting the font path setting to a path with a non-ascii symbol, and it worked. So it's probably fine.
Since IrrlichtMT does not use core::unicode::ustring anywhere except the header in which it is defined (or uses anything else defined in that header anywhere else), we will be able to remove the include/irrUString.h file from the IrrlichtMT repository, removing the last non-STL container from IrrlichtMT.