Luiz Americo Pereira Camara schrieb:
The codepage of a RawByteString at runtime will keep the previous
CodePage (65001 for UTF8, 1200 for UTF16) as opposed to change to the
RawbyteString CodePage (65535) as a though previously
Delphi defines RawByteString=AnsiString, so there is no room for UTF-16
in such an string.
So the implementation would be:
function FileGetAttr(const FileName: RawByteString): Longint;
begin
SetCodePage(FileName, 1200, True);
Won't work, because of "const", and because UTF-16 is not a Byte
(AnsiChar) string :-(
Result:=Integer(Windows.GetFileAttributesW(PWideChar(FileName)));
Delphi would use
Result:=Integer(Windows.GetFileAttributesW(PWideChar(string(FileName))));
with a temporary UnicodeString variable and an according try-finally block.
end;
This way the version using UnicodeString parameter would have the
benefit of being less verbose and use the possible optimizations of the
implicit encoding conversion.
At best it *hides* the temporary variables and implicit conversions, but
makes stringhandling more expensive. As I understand the FPC developers,
they want to reduce the number of implicit string conversions, what can
be achieved best with dedicated string types.
DoDi
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
