Hello,

The objective of UXStrings is Unicode and dynamic length support for
strings in Ada.

UXStrings API is inspired from Ada.Strings.Unbounded in order to
minimize adaptation work from existing Ada source codes.

Changes from last publication:
- Ada.Strings.UTF_Encoding.Conversions fix is no longer needed with GNAT
CE 2021
- A few fix

Available on GitHub (https://github.com/Blady-Com/UXStrings) and also on
Alire (https://alire.ada.dev/crates/uxstrings.html).

Feedback is welcome on actual use cases.

Regards, Pascal.

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

Le mardi 1 mars 2022 à 21:47:51 UTC+1, Blady a écrit :

Feedback is welcome on actual use cases.

Hello Pascal,
Thank you very much for this great improvement over Unbounded Strings !
Sure a short string optimization, such a the one implemented in GNATColl.XStrings, would be appreciated.
As a personnal taste, I would appreciate to have a UXCharacter type that is a Wide_Wide_Character, and an ASCII_Character, or a Char that is a subtype of it.
I think that the ASCII_String could be a derived type of UXString since it is a proper subtype, that specializes the UXString to only ASCII Characters. Some primitive operations can then be overriden to take advantage of the direct mapping between bytes
and characters.
Regards,
Vincent

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

Le 23/03/2022 à 10:42, Vincent D. a écrit :

Le mardi 1 mars 2022 à 21:47:51 UTC+1, Blady a écrit :

Feedback is welcome on actual use cases.

Hello Pascal,
Thank you very much for this great improvement over Unbounded Strings !
Sure a short string optimization, such a the one implemented in GNATColl.XStrings, would be appreciated.
As a personnal taste, I would appreciate to have a UXCharacter type that is a Wide_Wide_Character, and an ASCII_Character, or a Char that is a subtype of it.
I think that the ASCII_String could be a derived type of UXString since it is a proper subtype, that specializes the UXString to only ASCII Characters. Some primitive operations can then be overriden to take advantage of the direct mapping between

bytes and characters.

Hello Vincent,

I had some thoughts about "generic" Character concept and felt the user
would mostly choose Unicode representation (same as Wide_Wide_Character)
which brings the maximum available character set at a small cost of 4 bytes. Ada standard library comes will all sort of conversion subprograms to
ASCII, Latin-1...
Thus, for UXStrings, I choose Unicode_Character type as "generic"
character (which renames Wide_Wide_Character), see for instance: https://github.com/Blady-Com/UXStrings/blob/master/src/uxstrings1.ads#L58

May you be more specific?
What advantages for the user would bring a UXCharacter type?

egards, Pascal.

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

Le jeudi 24 mars 2022 à 22:13:40 UTC+1, Blady a écrit :

Thus, for UXStrings, I choose Unicode_Character type as "generic"
character (which renames Wide_Wide_Character), see for instance: https://github.com/Blady-Com/UXStrings/blob/master/src/uxstrings1.ads#L58

May you be more specific?
What advantages for the user would bring a UXCharacter type?

Hello Pascal,
We agree that a type for Unicode Code Point is mandatory. I find the name Wide_Wide_Character clumsy, and I would appreciate to have shorter names so as a personal taste I would simply prefer "Unicode" to "Unicode_Character".
Then I realize - and hence I contredict my own previous post - that the important concept for the user is the Grapheme cluster . So in fact a UXCharacter should simply be a subtype of UXString storing one Grapheme Cluster.
Just my 2 cents.
Regards,

Vincent

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

"Vincent D." <[email protected]> writes:

Then I realize - and hence I contredict my own previous post - that
the important concept for the user is the Grapheme cluster . So in
fact a UXCharacter should simply be a subtype of UXString storing one Grapheme Cluster.

Personally I like the semantic - I know this[1] is a macOS problem, but
it comes to something when you get a warning like

páck3.ads:1:10: warning: file name does not match unit name,
should be "páck3.ads"

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114#c1

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

On 30.03.22 21:53, Simon Wright wrote:

Personally I like the semantic - I know this[1] is a macOS problem, but
it comes to something when you get a warning like

páck3.ads:1:10: warning: file name does not match unit name,
should be "páck3.ads"

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114#c1

Slightly OT, varying the PR:

"Right. And people should use sane floating point types
(and sane CPUs to begin with)."

7-bit people have created much work in the past,
by insisting that human beings should succumb to ASCII.
Learn how to type. Start at LE vs BE if flexibility vexes you.
Even C was ahead of its time by defining plain char.
See gcc's -funsigned-char vs libraries.

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