Felipe Monteiro de Carvalho schrieb:
On Thu, Oct 20, 2011 at 5:30 PM, Luca Olivetti <[email protected]> wrote:
But you have to manually (or semi-automatically) do it, which is a lot of
work and possibly error prone.
While, with utf-16, you shouldn't change any routine name at all, unless you
have to deal with characters outside the BMP.
You say so, but while I cannot comment with certainty since I have
never used the Unicode Delphi, from what I read people had major
difficulties doing the migration. It was not at all easy. While for me
the migration from ansi to utf-8 was trivially easy.
The Ansi/UTF-16 migration is much easier than a migration to UTF-8. When
your legacy code can assume that every (visible) character is a Char, in
an SBCS codepage, this is not different in UTF-16. But the same is not
true for Ansi SBCS codepages whose characters can translate into
multi-byte sequences in UTF-8.
Changing the size of Char is not just small detail, this breaks *a
lot* of code. Any kind of memory operations such as Move will fail
because the char size changed.
Why would *application* code ever do low-level fiddling with *managed*
strings???
Not to mention people that were using PChar to address memory which is
not really a string =D suddenly the steps duplicate in size and your
whole memory layout changes...
Then replace all occurences of String by AnsiString, and Char by
AnsiChar (global find&replace). And replace all (eventual) usages of
UTF8String by AnsiString, to prevent possible encoding conversions. Then
all your code should work as before. Problems may arise from standard
text components (TStrings...), when these are not also available in Ansi
versions - but this only affects the runtime, due to implicit
conversions. This is where the RTL and FCL deserve some more
considerations, and the future will tell...
DoDi
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
