[fpc-devel] Save the current FPC UnicodeString!

[Florian Klaempfl]

Martin Schreiber schrieb:
> On Tuesday 10 November 2009 10:33:07 Florian Klaempfl wrote:
>>> So please don't destroy this ideal solution by dropping current FPC
>>> UnicodeString in favour of the Delphi string which is complicated,
>> Who says that? If you don't mess with code pages, the only different
>> you'll might see is that UnicodeString gets two new fields: encoding and
>> char size. However, this information is usually only used if you pass
>> the string to a RawString parameters. Normal Unicodestring routines
>> initialize these fields and that's it.
>>
> 
> I can confirm there is not much overhead for the new UnicodeString. I was 
> mislead by the Delphi {$stringchecks on} option and a misinterpreted comment 
> from a FPC developer that it is not possible to check codepage compatibility 
> at compiletime, sorry for that.
> Some guesswork gained form my experiments with the cpstrnew branch, Win32, 
> Russian locale, source in utf-8, {$codepage utf8}, please correct me if I am 
> wrong:

I'am not sure how far these things are already fixed/supposed to work.

> 
> What are the differences of AnsiString and RawByteString?

Ansistring: system encoding
RawByteString: variable encoding, cannot be checked at compile time,
when working with RawByteStrings, you've to take care of the newly
introduced encoding field