Недавно обновился компонент
Alcinoe до версии 4.0 и автор написал интересную ремарку к релизу:
- скрытый текст: показать
About Win64
Unfortunatly, in win64 we lost all the FastCode heritage.
(that was mostly based on ASM). That mean that most of
the functions will be around 2x to 10x more slower.
you can try to launch /demo/ALStringBenchMark/
in win64 and Win32 to see the difference in speed.
This Unfortunatly make the Win64 support of Delphi
like a "gadget", because most of the app demanding the
win64 support are Server App (or dll) and this king
of app need all the power. I just Hope that
embarcadero will improuve the speed of the win64
functions, but i doubt they want to do them in asm
because they want to go in multi plateforme, and
they not really want to do dedicated ASM for
every plateforme, they instead want to improuve
their compiler. but i thing it's an utopia that
their compiler will produce code that can compete
with handly optimized ASM
About Delphi D2009+ (Unicode)
No mistake, Unicode was necessary for a product like Delphi.
But the way embarcadero decide to implement it’s questionable!
Indeed they decide to migrate the 8bit string to 16bit string
instead of choosing to implement Unicode through 8bit string
(UTF8). This cause the migration of some Delphi app < d2009
very hard, especially on application that assume that string
is 8bit. Here a very good article about why to avoid to use
UFT-16: http://www.utf8everywhere.org/
The main argument of embarcadero why choosing UTF16 instead
of UTF8 is because the windows API work in the background in
UTF16 and better to stay in the same way as the windows API.
This is still questionable when the strategy becomes to make
Delphi a multi platform product.
So I was facing the need to choose: stay in D2007, move to
freepascal (that implement Unicode through UTF8) or migrate
to Unicode. After studying the Unicode migration and discover
that it’s will be very hard to do (even in the Delphi I
discover some bugs in their own source code due to the
migration from ansi to Unicode like for exemple
http://qc.embarcadero.com/wc/qcmain.aspx?d=106424).
Also on lot of my applications the migration to Unicode was
really unnecessary, as they was already working in UTF8,
receive their input request in utf8 and output their response
in UTF8. Here the migration to UTF16 will mean:
Input (UTF8) => UTF16 => data processing => UTF16 => output(UTF8)
+ off course all the migration job (that include debugging).
In fact, except the input/output to the "visual interface",
most (if not all) of the input/output of most of the
application will be done in 8bit string (ex: file storage,
client/server protocol, HTTP, Smtp, tcp, xml, html, database,
etc.). So I decide to go in Delphi Xe2 but to stay in
ansistring (8bit string). My first through was to replace
everywhere in my code all the String by AnsiString.
Unfortunately, most of the usefull and needed string function
in D2009+ are not available in 8bit string like inttostr,
strtoint, strtofloat, Tstrings, TstringStream, etc. that
simply unbelievable, in their way to go in 16bit string,
embarcadero remove the 8bit support ! of course we can still
do ansistring(inttostr(x)) but this is very pity (and slow).
So i decide to make my component like a "framework" to help
the fully support of 8bit string (mostly in UTF8).
I build a small application (available in /demo/ALStringToAnsiString/)
to convert all string type and string function to their
ansistring equivalent. The conversion reflects my
programming style and quirks so you may need to tweek the
output or modify the converter so you have the code. Will
this work for your code? Probably not out of the Non Box but
you may only be left requiring only few little tweaks.
You can also go in /demo/ALStringBenchMark/ to find an
application to benchmark ansiString vs Unicode String and
in /demo/ALSortedList/ to see the benchmark of TALStringList
(ansiString) vs TStringList (UnicodeString). In fact, most
of the Unicode function (when they are implemented correctly,
thanks to fastcode) will be close to the same speed as their
ansi equivalent. But no mistake, Unicode string will still
use 2x more memory and dependly of the application, this can
be not acceptable (exemple application that load huge list of
string in a TstringList or in an XML object).
Under D2009+, ansiString Have now a codepage, and some
transliteration (OldCodePage => UTF16 => NewCodePage) will
happen when assigning one ansiString with different codepage
to another ansistring with another codepage. To avoid this
it’s important to always set project option to the code page
you want (eg. 65001 for UTF8) and also to call at the
beginning of the program SetMultiByteConversionCodePage(CP_UTF8);
Also it’s very important to avoid to use 2 differents
string type (eg UTF8string and aniString) even if they have
the same codepage, because compiler at compile time
don’t know that codepage is the same and will do a
transliteration (ex MyAnsiStringUTF8 := MyUTF8String will
result in UTF8 => UTF16 => UTF8). This is why we use in
all our code only AnsiString instead of UTF8String (even
when we assume that string contain only UTF8 char) to
avoid theses transliteration keep the rule to only use
AnsiString with SetMultiByteConversionCodePage and not type
like UTF8string or other
Also about the compiler warning, when he detect a
transliteration you will have a warning, but he can not
always detect the transliteration Ex: MyFunctionNeedPWideChar(Pointer(aPansiChar))
Here unfortunatly you will not get any "warning" nor
any "error" from the compiler.
Everyone that want to join us in the development of this
8Bit string framework is welcome !
Интересным мне показался его способ поддержки юнкода: он просто взял и переименовал все
String в
AnsiString, и написал свою реализацию TStringList (ансишную). В осадке, он получил возможность компилировать проект в XE2 и избавился от головной боли с юникодом (к тому же, судя по его бенчмаркам, ансишные строки работают гораздо быстрее).
Выходит, таким макаром можно и САСа скомпилить в XE2? Гуй получится юникодным, а всё внутри, с большего, будет работать в анси (через framework alcinoe).
), у желающих скомпилировать исходники наверняка появятся вопросы. Вот тут их и предлагаю решать.
