This Ada library, providing Unicode character strings of dynamic length,
is enriched by a third implementation: UXStrings3 [1] also available on
Alire [2]. With this latter implementation, the characters are stored in Unicode form and the management of dynamic size uses the standard Wide_Wide_Unbounded strings library.

Performance with Gnoga [3] is better. UXStrings2 already brought better performance in the case of strings only made up of ASCII characters (improvement by a factor 2 to 3 compared to UXStrings1). With UXStrings3 performance in the latter case is still improved (factor 6 to 7 compared
to UXStrings1) moreover in the case of strings accentuated in French and strings containing emojis the process times are also improved (factor 7
to 8 by compared to UXStrings1 or even more in the case of emojis).

For all cases, the global memory occupation of the Gnoga application is generally similar (9 to 10 Mb). The memory occupation due to UXStrings3
is negligible compared to the memory occupation of the server engine implemented in Gnoga.

Study case: AdaEdit application using the Gnoga graphics library with
UTF-8 files:
English 315 kb
French: 447 kb
Emojis: 439 kb
Process: read all lines of the given file and display the full text

Regardless of the implementation chosen, the appealing of a library is
mainly based on the capabilities it offers (API). So far in UXStrings,
these are similar to those of the strings Ada standard libraries. If you
find some missing, make your proposals on Github [4].

Pascal.

[1] https://github.com/Blady-Com/UXStrings/blob/master/src/uxstrings3.ads
[2] https://alire.ada.dev/crates/uxstrings.html
[3] https://sourceforge.net/projects/gnoga
[4] https://github.com/Blady-Com/UXStrings/issues

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Pascal,

Thank you for this contribution. Here are some comments:
- since UTFString is a class ("a tagged record type"), why don't you create an abstract root "UXString" and then derive specialized object types ? Like UTF_8_XString, UTF_16_XString, ASCII_XString, Win_1252_XString, Latin_XString, etc.
- The default format to convert between different encodings should be UTF-8 as it is now ubiquitous.

[...] moreover in the case of strings accentuated in French and strings containing emojis the process times are also improved (factor 7 to 8 by compared to UXStrings1

- I find quite astonishing to have a factor 8 compared to UTF-8 encoding. Do you have an explanation ? This looks like a poor implementation because UTF-8 encoding is fast and allows direct manipulation in most cases. Maybe because random access is
treated as sequential access for UTF-8 encoded strings but this again is poor implementation.

Kind regards,

Vincent

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Vincent,

Le 29/06/2023 à 10:49, Vincent D. a écrit :

Hello Pascal,

Thank you for this contribution. Here are some comments:
- since UTFString is a class ("a tagged record type"), why don't you create an abstract root "UXString" and then derive specialized object types ? Like UTF_8_XString, UTF_16_XString, ASCII_XString, Win_1252_XString, Latin_XString, etc.

Well, that's a possibility chosen in some other Ada Strings libraries.
I've preferred that the API of legacy Ada "string" types to be closed to
those of Ada library so that the adaptation would be easy.
These are not intended to be used outside legacy code adaptation.
Note that I've renamed them as character arrays rather than strings in
order to accentuate the semantic difference.

- The default format to convert between different encodings should be UTF-8 as it is now ubiquitous.

Conversions are between UXString and encodings, not between encodings.

[...] moreover in the case of strings accentuated in French and strings containing emojis the process times are also improved (factor 7 to 8 by compared to UXStrings1

- I find quite astonishing to have a factor 8 compared to UTF-8 encoding. Do you have an explanation ? This looks like a poor implementation because UTF-8 encoding is fast and allows direct manipulation in most cases. Maybe because random access is

treated as sequential access for UTF-8 encoded strings but this again is poor implementation.

You got it: "most cases". Apart from complex implementations, if you
want to access a specific position you have to parse from the beginning
of the UTF-8 data as UXStrings1 does.
UXStrings2 always computes if the resulting data are all ASCII, so the
access is then direct.
UXStrings3 is internally like an Unicode array, so the access is direct.

Best regards, Pascal.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)