Delphi - kompatibilita starých projektov

Do verze 2007 by to mělo být na 99% bezpečné, pak přišlo Unicode a je otázkou, jak pracuješ se stringy. Pokud ale nepoužíváš nějaký extra-special-fičury či exotické komponenty, mohla by zdrojáky skousnout (a vyplivnout funkční kód) i poslední verze...
Zkus se podívat na tyhle články:
Verze Delphi (TP1 → XE7)
O verzích Delphi a mém snu

Pokud jsi pouzival standardni komponenty a nedelal zadne silenosti s dodelavanim podpory unicode do neunicode Delphi, pak to muzes docela bezbolestne prevest. Par starych utilit jsem z Delphi 7 do Delphi XE10 preklopil bez vetsi namahy.

Ďakujem za Vaše povzbudivé slová. Na ich základe som sa odvážil siahnuť po Delphi 10 starter, ktorá bola do konca minulého týždňa zdarma a skutočne som svoje staré projekty bez problémov previedol do Delphi 10. Zápasím teraz trochu s unicode pretože v projektoch, kde pracujem s veľkými poľami stringov sa mi zdá neefektívne, že string je namapovaný na unicode 16. Pri bežnej práci s textami a to aj s ohľadom na národné znaky by sa mi viac páčilo utf8, ktorý je zaiste úspornejší jednak vzhľadom na pamäť a tiež vzhľadom na veľkosť súborov, ak sa stringy ukladajú. Avšak predeklarovanie stringov na utf8string spôsobuje problémy s niektorými stringovými operáciami. Uvediem banálny príklad avšak skutočne len ako ukážku. Mal som tu napr algorytmus na zašifrovanie aj rozšifrovanie textu, kde som rôzne menil ascii hodnoty - teda banálna vec - a fungovalo to dobre pri neunicode Delphi a funguje to dobre aj v Delphi 10 ak je string defauldný unicode 16. Pri použití utf8string dochádza k rôznym nekompatibilitám napr:

s:string;
p:char;
i,j:integer;

for i:=1 to length(s) do begin
p:=s[i];
j:=ord(p)+20;
p:=chr(j);
end;

Teda banálna vec, ktorá "zašifruje" text a samozrejme obdobná procedúra ho zasa v opačnom poradí rozšifruje. Zámerne vynechávam ďalšie manipulácie. Ide len čiste o prístup k stringu jeho indexovanie a prevod byte na číslo a späť.

Pri hore uvedenej deklarácii prebehne kód dobre ale mám všetky stringy 4-bytové a neviem či to nie je zbytočné hlavne ak mám pole stringov so státisíce položkami a v neunicode aplikácii som tak spotreboval vyše 200 MB pamäte a teraz raz toľko.

Pri snahe zefektívniť kód urobím deklaráciu takto
s:utf8string;
p:utf8char
kompilácia vypíše nekompatibilitu
pri deklarácii
s:utf8string;
p:ansichar;
je kompilátor tiež nespokojný
pri deklarácii
s:rawbytestring;
p:ansichar;
je kompilátor spokojný ale pracuje to len so znakmi pod 128, národné znaky pokazí. Asi mi niečo pri manipulácii s utf8 uniká ale neviem čo. Viem že utf8 má variabilný počet byte na znak od 1 až po 6 ale myslel som že ak použijem vhodné typy, nemal by s tým byť problém.
Rovnako tak ukladanie do súboru som vždy riešil prostým

procedure WriteString(stream:TStream; s:string);
var len:integer;
begin
len:=length(s);
WriteInteger(stream,len);
stream.Write(s[1],len);
end;

a potom čítal

procedure ReadString(stream:TStream; var s:string);
var len:integer;
begin
ReadInteger(stream,len);
SetLength(s,len);
stream.Read(s[1],len);
end;

Vždy mi to v neunicode Delphi fungovalo. Teraz predeklarujem vstupné parametre na utf8string a už to nefunguje. Vždy zapíšem menej alebo viac len nie toľko čo treba. Opäť length by mal vrátiť reálnu dĺžku v znakoch ale počet bytov je iný a tým pádom sa neviem dobrať výsledku tak, aby som zapísal a následne prečítal presne to čo chcem, pretože neviem správne zistiť reálnu dĺžku stringu, zapísať ju a následne nastaviť pri čítaní pole nie podľa znakov ale bytov.

UTF-16 se ti zdá pro práci s řetězci neefektivní a raději bys používal UTF-8? A to ti nevadí, že nepůjde přistupovat k UTF-8 řetězci znak po znaku, ale vždy se to bude muset kódovat a dekódovat, protože všechny funkce pracují v UTF-16?
Jediná věc je velikost. Ale nic ti přece nebrání mít uloženo v ANSI, pokud to vyhovuje a unicode opravdu nepotrebujes.

Tak možno sa na to úplne vykašlem a ostanem pri unicode 16. Napokon v dnešnej dobe veľkých diskov a pamätí je jedno či má proces 200 alebo 400 MB pamäte. Hlavne že prechod na nové Delphi prešiel bez bolesti a ak človek ostane pri utf16 tak všetko šlape ako má. Tak ešte raz vďaka.

UTF-8 můžeš použít na ukládání do souboru. Tam to není tak tragické - při čtení to dekoduješ a při zápisu koduje do UTF-8 jednorázově.