Alcinoe Wiki

compoments suite for Delphi

Brought to you by: ak-74m, svanderclock, toledus

Home

Authors:

Alcinoe suite for Delphi

[ALMongoDBClient] - Delphi Client for MongoDB database
[ALJsonDocument] - a Delphi parser/writer for JSON / BSON data

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 !