Am 16.09.2011 17:19, schrieb Tomas Hajny:
Was your point about "string", or "RTLString"?I'm thinking about "string", but that is more directed towards the OOP parts, which assume a objfpc{$h+} or Delphi mode. So the base RTL functions like fileopen will be rawbytestring that accepts _all_ encodings, (so also ansi/utf8/utf16 in ansi/utf8/utf16 mode) and runtime convert if necessary and possible or explicitely typed. It depends on the amount of routines that don't fall into these categories if something like RTLSTRING is possible. Of course the "accepting" of all encodings is on interface levels. Implementations for platforms are dos are not supposed to support them all, just the ones they always did.OK, I see. I assume that an option to override the "string" meaning (similarly to current $H+/-) among ansi/utf8/utf16 would be created then (if not already available in cpstrnew), right?
At least in the JVM branch it exists already when using "{$modeswitch unicodestrings}{$H+}" (I don't know whether Jonas implement it generally or only for JVM though). See: http://wiki.freepascal.org/FPC_JVM/Language#String.2C_unicodestring_and_java.lang.String
Regards, Sven _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
