[fpc-pascal] Console Encoding in Windows (Local VS. UTF8)

[Michael Schnell]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20130729/4f1f6911/attachment.html>