Juha Manninen schrieb:
Then there is
FileExists --> FileExistsUTF8($1)
The idea is to add all file name related functions that have a ...UTF8
counterpart, and make their replacement optional somehow.
Now I would need more function names and parameters to replace. Other comments
are welcome, too.
I just wonder why special UTF8 functions are required at all. From the
user VP the use of UTF-8 arguments should not deserve different
procedures, overloaded procedures should be sufficient if ever required.
But this most probably is an FPC topic, about the distinction and
possibly automatic conversion between Ansi/MBCS, UTF-8 and UTF-16/Wide
strings.
If the type AnsiString had not been defined and used improperly in
Delphi, we could default String to ASCII or UTF-8 encoding, and have
more AnsiString or SBCS/MBCS string types with an explicit Encoding tag
included. AFAIK in Delphi it just turned out that the new AnsiString is
incompatible with older DLLs, due to the added Encoding tag. While such
a tag should be restricted to the Delphi RawByteString, the name is an
horrible misnomer - a RAW BYTE string IMO should have no encoding at
all, with no automatic conversion, also usable for e.g. binary data or
other locale-invariant content (lookup of nationalized text...). Instead
an EncodedString type could have an Encoding tag, so that eventually
required conversions etc. can be determined by the RTS.
DoDi
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
