[fpc-devel] cpstrrtl/unicode branch merged to trunk

[Michael Schnell]

On 09/10/2013 02:25 AM, wkitty42 at windstream.net wrote:
> i agree... ANSIstrings should be ANSI only... UTF8string and 
> UTF16string should be available and used where necessary,

And the "NewStrings" that can (defined statically and - if compiler 
magic is done accordingly - dynamically) be used with any encoding, 
should have a decent name. That is why I call them "NewStrings", but 
this of course is a transient and not a decent denomination.

Do we indeed need to always use the sometimes silly that are suggested 
by Embarcadero ?


> IMHO... this would seemingly allow for better control as well as 
> string conversion where necessary... 
After some initial concern and some researching, I feel that the 
Delphi-like way to implement this kind of strings ("quasi-dynamically" 
encoded strings, each containing definitions for code-word width (1, 2, 
4  - and extensible to 8 - Bytes) and encoding id (ANSI Code page and 
special values for other schemes such as UTF) is a really good idea, and 
auto-conversion can be implemented in a rather user-friendly manner.

Only - as pointed out in the other mail -, the Delphi compiler magic is 
lacking support for fully dynamically encoded String which IMHO is 
doable without any change to the (complex and critical) library and 
without a noticeable performance degradation, making the use of these 
beasts a lot more flexible - which is much more important with fpc than 
with Delphi itself.

Especially providing TStrings and friend (or in fact any library 
function) with an interface featuring a predefined encoding, IMHO, is 
not a desirable way to go for a system that is supposed to support 
multiple OSes and environments.

-Michael