On 07/29/2013 07:36 AM, Noah Silva wrote:
Using UTF16 for internal string handling is a sensible option.
It depends.
UTF-16 needs more memory used
Linux OS API in most cases is 8 Bit, while Windows OS API is 16 bit
Conversions are very expensive.
If you need to import export much data but don't do much calculating of
course using the the import/export format all over the place is sensible.
If you do many calculations, the type of calculation might suggest a
certain encoding.
To address your specific points:
1.Lazarus User API already supports UTF8 so far as I know.
I suppose this is bound to change once fpc has completed the move to
"new Delphi Strings".
2. TStringList could easily support both, but as long as the
conversion to/from other code pages (especially UTF8) is automatic, I
wouldn't mind.
I already delved into this in another thread here: I do believe that it
is easily possible to invent a string type that supports any encoding
and that can be used to create such a flexible TStringList, but this
needs additional compiler support in an way that is not anticipated by
Delphi. IMHO this is possible without risking noticeable performance
degradation in any of the thinkable application variants.
3. Not sure what class inheritance has to do with this...
If you do TSrtingList (in fact TStrings)that uses this new type in the
user-programmer interface it needs to be possible to derive classes from
those that use the fully Delphi compatible String types with predefined
encoding. The compiler magic needs to be done appropriately to handle
this cases, requesting automatic conversions (only) when necessary.
-Michael
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
