<p>Am 28.02.2014 09:37 schrieb "Michael Schnell" <<a href="mailto:mschnell@lumino.de">mschnell@lumino.de</a>>:<br>
><br>
> ..Continuing the never ending discussion ...<br>
><br>
> [ In one ore more other threads here I showed that (IMHO) it would be most sensible (and in fact not performance killing (!) ) way out of the multiple (statically defined) "new" String types with different encoding (with auto-conversion) to additionally support a fully dynamically encoded string type (with auto-conversion) - which needs some compiler magic - and use same as the base type for TStrings and it's siblings. ]<br>

><br>
> The growing popularity of "Generics" might suggest to call this String encoding "Generic", too, (to easily tell it from the Delphi-introduced "Raw", and the dedicated encoding types).<br>

><br>
> Regarding arguments for it's usefulness I came across that the Lazarus API currently forces TStrings to be UTF8 encoded while Delphi currently forces TStrings to be UTF16 encoded. IMHO the only way to prevent disastrous compatibility problems is to do TStrings being "Generic"encoded and with that allow for decent portability for both.</p>

<p>Problem: there is (currently) no string type that can handle ANSI, UTF-8 and UTF-16 at once. The first two are handled by AnsiString and the third by UnicodeString. And those two are not equal which would be important for overrides/overloads/inheritance. Without that your whole idea is useless.</p>

<p>Regards,<br>
Sven</p>