On 13.01.2011 18:57, Hans-Peter Diettrich wrote:
Widestring will also grind the application to a halt due to being COM
based
on Windows.
How that?
WideString on Windows has no reference counting, thus everytime a
WideString is assigned it needs to be copied.
When system encoding changes with the target platform, indexed access
to such strings can lead to different results. Unless the compiler
can read the coder's mind...
You don't have to. The Delphi model provides a stringtype for the system
encoding, and then as such all strings from the system can be labeled.
With
other stringtypes, the necessary conversions can be edited.
Indexed string access produces other results for Ansi and UTF-8 system
encoding. Such code is not portable, and the data (ini files) are not,
too. Allowing for UTF-8 as the system encoding will frustrate Windows
users (dunno whether Windows allows for such a system encoding), and
Linux users are frustrated when UTF-8 is disallowed.
Nearly all Windows API functions only allow single byte encodings or
UTF-16. The only functions that I'm aware of, that can use UTF-8
encoding is the console input/output API (if the codepage is set to
UTF-8) [and also file I/O APIs, but they don't assume any encoding].
Regards,
Sven
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
