cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

[Marco van de Voort]

In our previous episode, Michael Schnell said:
> > multi-encoding/multi-charsize. At the moment msestring=UnicodeString for FPC 
> > 2.4 which is perfect. I fear FPC will drop this simple solution where it was 
> > ahead of Delphi.
> 
> Hmmm. I suppose with Linux (using utf-8 for the GUI interface to the
> user programs), having the user program always use Widestring internally
> and convert any GUI input and output string will feature an enormous
> overhead.

The real GUI part is not the real performance dependant part. GTK2 slow
performance comes from little optimizations and portability layering, much
less design choices.

The only problem is the db-aware part and the few other widgets that can
have 100000 elements and more, like treeview. There mass conversion can
hurt, e.g. when loading the data into the widget.

That is probably solvable (caching, only translating at the moment of
viewing etc).
 
But in general I think codepage conversions are a different magnitude from
general processing.

> I feel that just handling the multi-encoding String-management record
> (with "encoding"6 and "character-size", which, in the case of GUI
> generated and "meant for GUI" Strings, always is equal), would not
> impose much overhead over using using the plain old String management
> with just "reference-counter" and "contents-pointer".

Neither do I. 

While I think it would be best to use native encoding on all platforms as
much as possible, that is an opinion. However not using native encoding for
general processing is nuts. So we need the UTF8 type anyway.