You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a follow-up to #2583 (comment). There are problems handling unicode strings like "Course: 145 °" or, as expressed in code "Course: 145 \u00B0".
I have made a test program (attached) and compiled it using wxWidgets 3.1.5 and 3.0. This is because as of current, Debian and Flatpak is built using 3.0 while Windows and MacOS is using 3.1.5. Test program triggers bugs also in examples described in https://docs.wxwidgets.org/3.0/overview_unicode.html, at least in 3.0.
The complete results are available as comments in the test program. To summarize:
Overall, we should use std::string when possible in new code, avoiding wxString. This is also recommended in the wxWidgets docs.
The correct way to use a unicode literal is a wide string, like L"Course: 145 \u00B0"
The unicode support in 3.0 is seriously broken.
varargs functions like wxPrintf() and wxString::Format() are susceptible to segfaults both in 3.0 and 3.1.5 when fed with narrow utf-8 strings, using the << operator also fails but without any segfault.
Using unicode literals on 3.0 requires hacks like wxString::Format(wxString("%c"), 0x00B0) as applied in 6eaeec1.
The correct thing here would be to update to wxWidgets 3.1.5 or perhaps 3.2 in next release (5.8.0) so we can avoid the hacks. See #2396
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
This is a follow-up to #2583 (comment). There are problems handling unicode strings like "Course: 145 °" or, as expressed in code
"Course: 145 \u00B0"
.I have made a test program (attached) and compiled it using wxWidgets 3.1.5 and 3.0. This is because as of current, Debian and Flatpak is built using 3.0 while Windows and MacOS is using 3.1.5. Test program triggers bugs also in examples described in https://docs.wxwidgets.org/3.0/overview_unicode.html, at least in 3.0.
The complete results are available as comments in the test program. To summarize:
L"Course: 145 \u00B0"
wxString::Format(wxString("%c"), 0x00B0)
as applied in 6eaeec1.The correct thing here would be to update to wxWidgets 3.1.5 or perhaps 3.2 in next release (5.8.0) so we can avoid the hacks. See #2396
Test program: foo.cpp.gz
Beta Was this translation helpful? Give feedback.
All reactions