The matter is quite straightforward:Objectively false, "text" is never actually straightforward despite what it seems like on a surface level :P
1. Never ever use Wide and Wide_Wide. There is a marginal case of Windows API where you need Wide_String for UTF-16 encoding. Otherwise, use cases are absent. No text processing algorithms require code point access.Somewhat inclined to agree with Wide_<> but I don't see strong justification to *never* use Wide_Wide_<>, there's pretty substantial tradeoffs to both using UTF-32 and UTF-8 (in any programming language that supports both, but particularly with Ada's string situation) so unfortunately it ultimately falls on the programmer to understand and choose.
2. Use Character as octet. String as UTF-8 encoded.Perfectly valid, explicitly mentioned as an option in my post. Maybe actually would be better for most applications because they wouldn't need to transcode it, I should've noted that more clearly in my original response. The only two issues: make sure to avoid the Latin-1 String routines unless you know you're doing is sound; and in older Ada versions I remember reading long debates about the String type may not be able to safely store UTF-8 on many compilers (of the era), but that issue was clarified by even Ada 95 IIRC.
I just personally prefer Wide_Wide_<> to get its slightly more Unicode-aware string routines, but it's not the only (or even inherently the best) option.
~nytpu
--
Alex // nytpu
https://nytpu.com/ - gemini://nytpu.com/ - gopher://nytpu.com/
| Date | Sujet | # | Auteur | |
| 2 Sep 25 |  Re: Ada 202x; 2022; and 2012 and Unicode package (UTF-nn encodings handling) | 2 | Dmitry A. Kazakov | |
| 2 Sep 25 |   Re: Ada 202x; 2022; and 2012 and Unicode package (UTF-nn encodings handling) | 1 | Alex // nytpu |
Les messages affichés proviennent d'usenet.