[fpc-devel] Encoded AnsiString
mschnell at lumino.de
Tue Jan 7 12:56:16 CET 2014
On 01/07/2014 12:27 PM, Michael Van Canneyt wrote:
> if you have use-case 1 (which I doubt, since it is not possible even
> today) then you're better off using unicodestring anyway.
My argumentation is driven by the experience (some myself, a huge lot by
my colleagues) with doing "embedded" M2M-communication projects with
multiple protocols and applications (included in the project and/or
predefined by customers) and with some programs requiring sophisticated
user interaction in multiple languages.
The projects originally were done (mine still are done) using old
Here, strings are used as well to handle texts as to handle byte
streams (that might contain binary data or might contain text in
On top of that, the embedded handling of mass-data here needs to be very
fast, handling multiple TCP/IP interfaces at the same time..
Here, of course, for binary strings 8 Bit characters are the only
appropriate choice, while for the multi-language text supposedly the
best choice is using the encoding the underlying OS offer (e.g. UTF-16
for Windows) throughout the multiple units of the project.
So we are burned regarding the flexibility and the pitfalls of using
strings in multiple encoding variants within a single project, leading
to the urgent request for allowing to use any TString sibling (in own
code and in the RTL) in a way that allows for using arbitrary encoding
without forced re-encoding under the hood, if not absolutely necessary.
More information about the fpc-devel