[fpc-devel] Save the current FPC UnicodeString!

[Jonas Maebe]

On 10 Nov 2009, at 15:05, Felipe Monteiro de Carvalho wrote:

> But for GUI software the conversion speed impact is tiny, and the
> head-ache caused be a string type whose encoding is not know is by far
> much worse. Tons of string related code will stop working and need to
> be adapted at the gain of a couple of microseconds.

Generic unicode strings are not there for speed; their purpose is  
flexibility.

> I don't see why FPC is going in the contrary direction of most of it's
> users and offering the contrary of what is desired (= fixed encoding
> strings).

You can use those as well. At least in D2009, you can declare a  
unicode string with a particular code page, and everything assigned to  
that string will be converted to that codepage.

> Sure you can claim you know better then us what is good for
> our software, but I don't see how that will end up well.

Currently, the Unix rtl is built around ansistrings. The Mac OS X BSD- 
level filesystem functions however always require that their input is  
in UTF-8, and their output is also always in UTF-8. This is regardless  
of the LANG and of the LC_TYPE environment variables. Input from the  
keyboard will and to the terminal are of course in whatever encoding  
you set using those environment variables.

Currently, it is impossible to express this in the RTL. The new string  
type will make that possible, and generic unicodestrings without a  
forced type will mean that
a) you can pass in anything with an arbitrary encoding
b) the RTL will take care of the necessary code page conversions when  
necessary (and unnecessary ones can be avoided to some extent)


Jonas