Compilerfehler, aber wie Abhilfe schaffen

[Rudy Velthuis]

Zitat von peterbelow:

Zitat von skoschke:

Etliche Proceduren, bei denen Objekte als const deklariert sind, die dann aber innerhalb der Procedure beschrieben werden!

Da kommt natürlich "der linken Seite kann nichts zugewiesen werden"!
Das scheint aber in XE6 noch kompilierbar gewesen zu sein, oder gibt es da auch noch einen Schalter der das zulässt?

Nein. Aber normalerweise kann man ein Object als const-Parameter übergeben, wenn man innerhalb der Methode dann nur seine Properties ändert. Was man nicht ändern kann (und auch niemals tun sollte, wenn der Parameter nicht als var oder out deklariert ist) ist, dem Parameter innerhalb der Methode ein neues Objekt zuzuweisen. Das ist auch dann ein konzeptioneller Fehler, wenn der Parameter ohne const deklariert wurde.

Es ergibt aber selten Sinn, Objekte als const zu übergeben, dam man immer noch die Methoden aufrufen kann, und immer noch Properties setzen kann. Der Zeiger (die Objektreferenz) ist const, nicht das Objekt selber.

Zitat:

Ich finde es übrigens sehr bedenklich, wenn eine DLL Funktionen exportiert, die Delphi-spezifische Datentypen wie TStrings verwenden. Sowas funktioniert normalerweise nicht ohne massive Probleme.

Genau. Wer Englisch lesen kann sollte wirklich mal meinen Artikel lesen: DLL dos and don'ts. Der zeigt, was man alles machen kann und soll und vor allem, nicht machen sollte.

[Rudy Velthuis]

Zitat von peterbelow:

Zitat von skoschke:

Etliche Proceduren, bei denen Objekte als const deklariert sind, die dann aber innerhalb der Procedure beschrieben werden!

Da kommt natürlich "der linken Seite kann nichts zugewiesen werden"!
Das scheint aber in XE6 noch kompilierbar gewesen zu sein, oder gibt es da auch noch einen Schalter der das zulässt?

Nein. Aber normalerweise kann man ein Object als const-Parameter übergeben, wenn man innerhalb der Methode dann nur seine Properties ändert. Was man nicht ändern kann (und auch niemals tun sollte, wenn der Parameter nicht als var oder out deklariert ist) ist, dem Parameter innerhalb der Methode ein neues Objekt zuzuweisen. Das ist auch dann ein konzeptioneller Fehler, wenn der Parameter ohne const deklariert wurde.

Es ergibt keinen Sinn, Objekte als const zu übergeben. Nur die Objktreferenz ist dann const, nicht die Properties und Methoden. Sowas wie const-Methoden wie in C++ gibt es für Delphi nicht.

Zitat:

Ich finde es übrigens sehr bedenklich, wenn eine DLL Funktionen exportiert, die Delphi-spezifische Datentypen wie TStrings verwenden. Sowas funktioniert normalerweise nicht ohne massive Probleme. DLL und Anwendung müssen auf jeden Fall mit der gleichen Delphi-Version kompiliert werden und sie müssen einen gemeinsamen Memory-Manager verwenden (z. B. in dem man beide mit run-time packages baut, und dann kann man auch gleich eine Package statt einer DLL erzeugen). Wenn man eine DLL haben will, die unabhängig von der Delphi-Version des Hostprogrammes ist und eventuell sogar von anderen Programmiersprachen aus nutzbar ist darf man nur API-Level Datentypen verwenden, oder zumindestens COM-kompatible.

[/QUOTE]

Wer Englisch lesen kann, sollte meinen Artikel über DLLs lesen: "DLL dos and don'ts". Da wird beschrieben, was man beim Schreiben von DLLs machen kann und sollte und vor allem, was man nicht machen sollte. Delphi-spezifische Typen sollte man tunlichst vermeiden.

[DieDolly]

Zitat:

Delphi-spezifische Typen sollte man tunlichst vermeiden.

Außer man schreibt die Unit für sich selber nur für Delphi.

[peterbelow]

Zitat von DieDolly:

Zitat:

Delphi-spezifische Typen sollte man tunlichst vermeiden.

Außer man schreibt die Unit für sich selber nur für Delphi.

Selbst das funktioniert nur, wenn man DLL und Hostprogramm mit der gleichen Delphi-Version und Sharemem baut.