|
From: | Paolo Redaelli |
Subject: | Re: Libunicode |
Date: | Fri, 7 Jan 2022 00:05:15 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 |
Sounds great for me. In this case I think we should not go with a simple generated wrapper, but have to really integrate it to be used with the manifest unicode strings U"", we should support utf-x encoded source files with direct unicode characters and not to forget a good set of test cases and examples to make it easy to use and robust.
I didn't dare proposing such a change. 😁
Yet I think we should, as Unicode is a basic need of todays
standards.
I suggest to statically link it in order to avoid a runtime
dependency.
In fact I think it is a good thing that programs compiled by liberty do not have any dependencies other than libc.
Yet I would rather avoid the approach of GoLang of statically linking.
Last time I compiled obs-cli ( https://github.com/muesli/obs-cli
) a simple command line tool made in golang to control remotely
OBS (Open BroadCaster Studio) it created a 6,0MB binary from 26758
bytes of source. A stripped binary.
Also binaries made by Liberty aren't usually lean'n'slim, but I would rather avoid to statically link everything, being unicode support a notable exception, at least initially. Currently libunistring is a 2,3Mb static library or a 1,6Mb dynamic one. A good design would allow to let the developer choose if libunistring shall be linked statically or dynamically.
UNICODE_STRING is externally a TRAVERSABLE[INTEGER] and
internally uses a NATIVE_ARRAY[INTEGER_16] UTF-16NE encoded.
libunistring supports Unicode strings in three representations:
uint8_t
).
uint16_t
).
uint32_t
).
which one shall we support?
I would make UNICODE_STRING deferred with UTF8_STRING, UTF16_STRING and UTF32_STRING as effective heirs, where current UNICODE_STRING would became the new UTF16_STRING.
I also searched eiffel.org and gobo eiffel for some hints. Aren't
they the "professionals"?
I wasn't able to find a browsable documentation of their Unicode
classes. My fault or theirs?
It seems to me that you, in your spare time and working almost alone provides better documentation for Liberty classes.
[Prev in Thread] | Current Thread | [Next in Thread] |