Vordefinierte Delphi-Bezeichner Char & String umdefinieren?

[Andreas13]

Hallo Community,

ich möchte „alte“ Delphi-Bibliotheken aus den Jahren 2002 – 2004 „reanimieren“, weil sie damals einfach exzellent funktioniert haben und heute auch noch sehr gute Dienste leisten würden.

Dabei ergibt sich folgendes Problem:

Die Typen Char und String hatten damals noch andere Bedeutungen.

Meine – leider NICHT funktionierende – Idee sieht so aus:

Delphi-Quellcode:

Type
  Char   = AnsiChar;
  String = AnsiString;

Der Compiler (Delphi XE5 Professional) mag das allerdings nicht.

Geht es überhaupt so oder ähnlich, auf einen Schlag, oder muß man in kilometerlangen Quellcodes überall die Änderungen per Hand vornehmen und anpassen?
Vielleicht kennt jemand einen einfacheren Weg.

Danke & Gruß

Andreas

[hoika]

Hallo,
leider geht wohl nur 2. Weg.

[mkinzler]

Noch besser wäre es die Bibliothek gleich nach Unicode zu portieren.

[hoika]

Hallo,
kommt auf die Bibliothek an.
Lass da mal ein AnsiChar-String-Operationen als PAnsiChar+ drin sein ...

[Rollo62]

Ich würde auch eine radikale Überarbeitung vorziehen,
oder zumindest die Libraries erstmal in Lib_Alt.pas und Lib_Neu.pas doppeln, so dass man in Lib_Neu.pas immer bei Bedarf die benötigten Funktionen rüberziehen und überarbeiten kann (on Demand).
So lange bis irgendwann Alles korrekt in Lib_Neu.pas überarbeitet ist.

Dann könnten alte Apps wie gehabt mit Lib_Alt.pas laufen, und neue Apps die verbesserte Lib_Neu.pas nutzen.

Wenn Lib_Alt.pas dann endlich komplett überflüssig ist, könnten auch alte Apps auf die (hoffentlich) kompatible Lib_Neu.pas umgestellt werden
(Unit-Tests würden helfen).

Evtl auch erstmal grob Alles überarbeiten, und in einem Zwischenschritt eigene, neue Typen verwenden

Delphi-Quellcode:

Type
  MyLibChar = AnsiChar;
  MyLibString = AnsiString;

Dann wäre zumindest weniger Verwechslungsgefahr gegeben,
und die Überarbeitung der Library könnte klarer und sauberer dargestellt werden.

Wenn es denn am Ende läuft könnten die Typen einfach mit Rename in den ganzen Files umbenannt werden, falls nötig.

[freimatz]

Zitat von Andreas13:

Delphi-Quellcode:

Type
  Char   = AnsiChar;
  String = AnsiString;

Der Compiler (Delphi XE5 Professional) mag das allerdings nicht.

Warum nicht gleich so umbenennen?

[peterbelow]

Zitat von Andreas13:

Hallo Community,

ich möchte „alte“ Delphi-Bibliotheken aus den Jahren 2002 – 2004 „reanimieren“, weil sie damals einfach exzellent funktioniert haben und heute auch noch sehr gute Dienste leisten würden.

Dabei ergibt sich folgendes Problem:

Die Typen Char und String hatten damals noch andere Bedeutungen.

Meine – leider NICHT funktionierende – Idee sieht so aus:

Delphi-Quellcode:

Type
  Char   = AnsiChar;
  String = AnsiString;

Der Compiler (Delphi XE5 Professional) mag das allerdings nicht.

Der Compiler hat immer recht . Das kann nicht funktionieren.

Die Portierung nach Unicode (also Char = Widechar, String = Unicodestring, PChar = PWidechar) muss nicht so aufwendig sein wie Du glaubst. Nach meiner Erfahrung mit der Umstellung seinerzeit kompiliert der Löwenanteil des alten Kodes ohne Probleme und funktioniert sogar noch. Falls Du einen Satz halbwegs vollständiger Unittests für den alten Kode hast kann man auch Problemfälle schnell finden.

Das sind insbesondere:

• Kode, der annimmt, Sizeof(Char) = Sizeof(Byte)
• Kode, der Strings als Speicher für binäre Daten mißbraucht
• Kode, der Strings in Dateien speichert oder aus diesen liest (muss aber kein wirkliches Problem sein)
• Kode, der mit externen DLLs interagiert, die PAnsiChar als Parameter erfordern

Wenn Du alten Kode wiederverwenden willst, mach Dir die Mühe, ihn ordentlich auf Unicode zu portieren, und falls Du noch keine Unittests hast, schreib welche. Das ist zwar jetzt mehr Aufwand, aber es vermeidet jede Mengen Probleme in der Zukunft.

[Andreas13]

Danke für alle Tipps und Hinweise!

Gruß, Andreas

[Rudy Velthuis]

Zitat von Andreas13:

Danke für alle Tipps und Hinweise!

Gruß, Andreas

Peter Below hat recht. Die Portierung nach Unicode (also UnicodeString statt AnsiString, usw.) lässt sich oft viel leichter erzielen als man denkt. Da wurde alles schon so gemacht, dass man meistens nur neu kompilieren und dann die paar Fehler oder Warnungen die auftreten beseitigen muss. Dann noch testen und voilà!