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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
