Klassen-Funktion benutzen, ohne die Klasse zu erstellen

[guinnes]

Zitat:

Zitat von Medium (Beitrag 1062301)

Dass dies vom Compiler nicht bemeckert wird, sollte daher als Bug angesehen werden.

Das kann der Compiler schlicht und ergreifend nicht prüfen. Du hast einen Instanzzeiger ( wenn der auch auf NIL weist ) und über diesen Zeiger rufst du eine Methode auf.
Anders wäre es, wenn du TIrgentwas.Methode aufrufst. Da kann der Compiler prüfen, on es sich bei der Methode um eine Klassenmethode handelt und tut das auch.
Wenn die Gültigkeit der Instanz zur Laufzeit jedes mal geprüft werden würd, würde das auch nichts bringen, weil
1. Jede Menge Zeit verplempert würde und
2. Nichts anderes ans eine Fehlermeldung geworfen werden könnte

[Medium]

Eine Fehlermeldung wäre ja schon mal was ;). Und eine Prüfung auf nil ist soooo teuer nun auch nicht, da laufen z.B. in managed Umgebungen ganz andere Dinge unsichtbar ab. Wenn die Instanz nicht nil, und dennoch ungültig ist - das ist was anderes. Dann kann ich ja auch auf die Felder zugrifen und erhalte lustige Dinge.
Und ja, der Debugger wäre wohl eher geeignet an dieser Stelle. Es müsste schlicht eine Exception her.

[himitsu]

Zitat:

Zitat von x000x (Beitrag 1062294)

Warum zufällig?

Ja OK, von seiten Delphis ist es "absicht", aber von seinen des Programmierers und in Anbetracht, daß er keine Ahnung hatte, was er macht, war es eher Zufall, daß er z.B. kein Feld verwendet hatte. :angle:

[guinnes]

Natürlich ist eine Prüfung auf NIL nicht so aufwändig ( mindestens 4 Zusätzliche Assembler-Anweisungen ), aber sie müßte vor jeder Benutzung der Klasse erfolgen, das macht sie so aufwändig.
Und eine Fehlermeldung zu werfen, wenn die korrekte Arbeitsweise der Klasse sichergestellt ist, finde ich recht unsinnig

[Uwe Raabe]

Zitat:

Zitat von Medium (Beitrag 1062315)

Eine Fehlermeldung wäre ja schon mal was ;). Und eine Prüfung auf nil ist soooo teuer nun auch nicht, da laufen z.B. in managed Umgebungen ganz andere Dinge unsichtbar ab. Wenn die Instanz nicht nil, und dennoch ungültig ist - das ist was anderes. Dann kann ich ja auch auf die Felder zugrifen und erhalte lustige Dinge.
Und ja, der Debugger wäre wohl eher geeignet an dieser Stelle. Es müsste schlicht eine Exception her.

Ich sehe hier weder einen Grund für eine Fehlermeldung, noch für eine Exception. Der Aufruf

Delphi-Quellcode:

FTest.Test(str);

wird vom Compiler implizit umgewandelt in so etwas wie

Delphi-Quellcode:

TDummyClass.Test(FTest, str);

. Solange innerhalb der Methode nicht auf Self (= FTest) zugegriffen wird, ist doch egal, ob das nil ist. Wenn ich aber darauf zugreife, wird eine Nil-Referenz ausgelöst und da wäre dann ja die Exception.

Der Compiler könnte allenfalls einen Hinweis auswerfen, daß die Methode vielleicht besser als Class-Method deklariert werden sollte, aber mehr braucht's IMHO nicht. Eine generelle Überprüfung von Self auf nil halte ich für Verschwendung.

Übrigens funktioniert auch folgendes:

Delphi-Quellcode:

FTest := nil;
FTest.Free;

Die Implementierung von Free prüft dabei explizit auf

Delphi-Quellcode:

Self <> nil

. Eine solche Überprüfung kann selbstverständlich auch in jeder anderen Methode einer Klasse erfolgen und nach Gusto auf das Ergebnis reagiert werden. Muss ja nicht immer 'ne Exception sein.

[himitsu]

@Uwe: Es wird da nichts implizit umgewandelt.
Es bleibt ein Aufruf einer stinknormalen Methode,
nur daß "Self" eben nil ist (da hier praktischer Weise dieses von der Elternklasse so initialisiert wurde) und wenn man intern nun nichts nutzt, welches das Objekt benötigen würde, dann fällt es nicht auf.

PS: Wäre das FTest eine lokale Variable gewesen, dann hätte Self auf sonstwas stehen können und eine Prüfung auf NIL hätte meistens nichts gebracht.

[guinnes]

Zitat:

Zitat von Uwe Raabe (Beitrag 1062321)

Der Compiler könnte allenfalls einen Hinweis auswerfen, daß die Methode vielleicht besser als Class-Method deklariert werden sollte, aber mehr braucht's IMHO nicht.

Das Problem an der Stelle ist : Woher sollte der Compiler das wissen ?

[Medium]

Eine Exception wäre imho sehr wohl angebracht! Ich weiss, dass es technisch gesehen keinen Grund dafür gibt, es ist viel mehr eine Frage davon, in wie weit man die Paradigmen der OOP erzwingen möchte. Evtl. ist das mit Arraygrenzen vergleichbar: Es gibt technisch gesehen keinen Grund, beim Griff vor oder hinter ein Array zu meckern - der Speicher ist ja da. Es wiederpricht nur der Theorie des Arrays, welches nicht vorsieht länger zu sein, als es ist. Hier hat Delphi mit der Bereichsprüfung die Wahl geschaffen, ob man diese Hilfe haben mag oder nicht, was imho auch ein gangbarer Weg wäre. Nicht alles was praktisch möglich ist, ist mit der Theorie zu vereinbaren. Man muss sich nur für eines entscheiden.

[guinnes]

Zitat:

Zitat von Medium (Beitrag 1062364)

Evtl. ist das mit Arraygrenzen vergleichbar: Es gibt technisch gesehen keinen Grund, beim Griff vor oder hinter ein Array zu meckern - der Speicher ist ja da.

Schlechter Vergleich. Wenn du vor oder nach einem Array schreibst, veränderst du ungewollt andere Daten ( wenn du ließt, ließt du garantiert was falsches ). Ein Vergleich zu deinem Vergleich : :wink:
Es ist wie irgendjemanden auf der Straße in die Geldbörse zu greifen. Rein Technisch ist das Geld ja da :wink:

[Medium]

Du willst mich nicht verstehen :cry: