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