TJC Support writes:
Quote
"Rudy Velthuis [TeamB]" <XXXX@XXXXX.COM>writes
news:XXXX@XXXXX.COM...
>
>Since the VCL and RTL will mainly be unicode, if you keep on using
>AnsiStrings (by switch or explicitly), every communication with VCL
>and RTL would mean a conversion and often also a conversion in the
>other direction. This could lead to loss of data (Unicode to
>AnsiString), so I am not so sure this is a good scenario.
And of course, if you did have Ansi VCL/RTL like we have now, then a
conversion takes place when the VCL makes a call to the OS. So
either you are 100% Unicode-based, or there's a conversion taking
place somewhere.
The advantage of using the string type instead of the fixed size
AnsiString is that code will compile under both compilers, Delphi 2007 and
the new Delphi (I assume that will be D2008) without any problems and
without having to "ansify" your code. The OS may convert AnsiString to
an unicode string internally, but the RTL and VCL won't do that, and
these do not necessarily call the OS for everything they do. So any
communication with these will require extra conversions you can avoid
by suing the standard "string" type.
Also, if you use AnsiString throughout, but the default API changes
from ansi to wide, then passing PAnsiString(myString) to a (now) wide
version of the API causes problems I don't want to face, or requires me
to explicitly convert the AnsiString to a unicode string first, before
calling the API. This means more code I must write, which is a big
source for errors (especially since this is something that could easily
be forgotten).
The best way to handle this and many more issues is to avoid using
explicit types, and to use the standard "string" type, which maps to
AnsiString in Delphi 2007 and to the new unicode string type in D2008. In
many cases, you won't probably notice any difference.
--
Rudy Velthuis [TeamB]
www.teamb.com
"Mother-in-law = A woman who destroys her son-in-law's peace of
mind by giving him a piece of hers." -- Anonymous.
