Klassen-Funktion benutzen, ohne die Klasse zu erstellen

[guinnes]

Zitat von Medium:

Du willst mich nicht verstehen

Das mag so sein, oder du mich nicht ?
Es ist schon ein Unterschied, ob in der Exe das steht :

Delphi-Quellcode:

DreckMain.pas.78: Caption := fClass.Foo(S);
004666AD 8D4DF8           lea ecx,[ebp-$08]
004666B0 8B55FC           mov edx,[ebp-$04]
004666B3 8B83E0020000     mov eax,[ebx+$000002e0]
004666B9 E81AFFFFFF       call TMyClass.Foo
004666BE 8B55F8           mov edx,[ebp-$08]
004666C1 8BC3             mov eax,ebx
004666C3 E8F4CCFBFF       call TControl.SetText

oder das :

Delphi-Quellcode:

DreckMain.pas.77: if fClass <> nil then
004666AE 8BB3E0020000     mov esi,[ebx+$000002e0]
004666B4 85F6             test esi,esi
004666B6 7417             jz TForm1.Button1Click + $47
DreckMain.pas.78: Caption := fClass.Foo(S);
004666B8 8D4DF8           lea ecx,[ebp-$08]
004666BB 8B55FC           mov edx,[ebp-$04]
004666BE 8BC6             mov eax,esi
004666C0 E813FFFFFF       call TMyClass.Foo
004666C5 8B55F8           mov edx,[ebp-$08]
004666C8 8BC3             mov eax,ebx
004666CA E8EDCCFBFF       call TControl.SetText

Vor allem, weil die Funktionalität gleich ist

[shmia]

In den Compileroptionen gibt es Bereichsüberprüfung, I/O-Prüfung und Overflow checking.
Was jetzt noch fehlt wäre ein Self-Pointer-Check.
Gibt's das eigentlich schon als Feature-Request bei Embacadero?
Während der Programmentwicklung würde man die Compileroption setzen und später wenn das Programm seine Quatlität bewiesen hat die Option wieder rücksetzen. (was Speicherplatz und Zeit spart)

[himitsu]

Du könntest ja einfach in alle Methoden dieses Einfügen.
Assert(Assigned(Self) and (TObject(Self) is TKlassentyp)); .

Aber stimmt schon, sowas könnte Emba eigentlich auch intern via Compilerschalter reinbauen.

PS: Es wäre auch schonmal schön, wenn z.B. diese Überlauf- und Bereichsprüfung standardmäßig aktiviert wäre.

[schöni]

Zitat von x000x:

Zitat von mkinzler:

Klasenmethoden funktionieren unabhängig von Instanzen. allerdings handelt es sich in deinem Fall um eine normale Methode

Ja, das ist mir bekannt - dann hätte ich class davor schreiben müssen und der Aufruf wäre dann TDummyClass.Test. Das steht dort aber nicht und trotzdem funktionierts.

Werden denn beim Erstellen einer Instanz mit FTest:= TDummyClass.Create; nur die Felder initialisiert? Vermutlich ja, dann macht das auch Sinn das es funktioniert.
Sobald ich dann aber auf Felder der Klasse zugreife, dann knallts.

Ok, ich denke ich verstehe... Vielen Dank

Die aufgerufene Methode ist ausserdem statisch, die Klasse hat keinen Vorgänger mit viertuellen Methoden. Somit ist diese Klasse auch ohne Konstruktoraufruf uneingeschränkt benutzbar. Mich wundert, das das in diesem Fall bei Feldern der Klasse nicht funktionieren soll, sofern die Felder public definiert sind. Probleme könnte es dann höchstens bei Eigenschaften geben, die ja intern im Stream gespeichert werden, was der Compiler geschickt verbirgt.

[himitsu]

Zitat von schöni:

Mich wundert, das das in diesem Fall bei Feldern der Klasse nicht funktionieren soll, sofern die Felder public definiert sind.

Zugriffe auf Felder und virtuelle/dynamische Methoden werden über einen Offset zu Self ausgeführt.
Ist nun Self = nil oder ein ungültiger Wert, dann geht das natürlich schief.

[Medium]

Zitat von guinnes:

Es ist schon ein Unterschied, ob in der Exe das steht :
{...}
oder das :
{...}
Vor allem, weil die Funktionalität gleich ist

Öhm... die Bereichsprüfung ist wohl mindestens genau so "schlimm", und da man Arrays für Gewöhnlich in Schleifen durchläuft, tendenziell sogar öfter am Zuge. Die paar Püpschen machen doch wohl, als schaltbare Option, zum Debuggen wohl kaum wat schlimmes. Im Gegenteil, es hilft ggf. sogar. Und selbst wenn es dauerhaft drin wäre, wäre es im Normalfall noch immer vernachlässigbar. Lediglich in Fällen, in denen hochoptimierter Code wirklich von Nöten ist - und dort würde ich ohnehin so gut wie geht OOP-Overhead vermeiden, und maximal auf Records setzen, wenn es schon strukturiert sein muss. Allerdings: Die meisten derartig auf Speed gezüchteten Dinge setzen auf primitive Datentypen, Arrays dieser, und inline-Prozeduren. Klassen kommen also quasi "natürlicherweise" dort nicht vor, wo dieser Mehraufwand merkbar wäre. Das alles vorausgesetzt, es wäre keine Option, wie ich vorschlug.
Normalerweise bin ich doch hier der kleinliche Optimierungs-Eumel

[guinnes]

Zitat von Medium:

Normalerweise bin ich doch hier der kleinliche Optimierungs-Eumel

Wenn du auf einer Maschine mit 32KByte die Grundzüge der Programmierung gelernt hast, prägt dich das dein restliches Leben

[alzaimar]

Zitat von guinnes:

Wenn du auf einer Maschine mit 32KByte die Grundzüge der Programmierung gelernt hast, prägt dich das dein restliches Leben

Was für ein Luxus.

So ganz verstehe ich die Diskussion nicht. Eine Methode ohne jeglichen Bezug zum Objekt wird über eine ungütlige Instanz aufgerufen und richtet keinen Schaden an.
Wo ist der Fehler?
Nirgens*. Es funktioniert, es schadet nicht, hat keine Seiteneffekt usw.

*Natürlich ist da ein Fehler. Der sitzt vor dem Rechner und bemerkt es nicht einmal: Eine Methode ohne Bezug zum konkreten Objekt ist eine Klassenmethode.

Zitat von shmia:

...Was jetzt noch fehlt wäre ein Self-Pointer-Check.

Den gibt es schon und nennt sich FastMM.

Zitat von himitsu:

Du könntest ja einfach in alle Methoden dieses Einfügen.
Assert(Assigned(Self) and (TObject(Self) is TKlassentyp)); .

Nun ja. Hilft das bei bereits freigegebenen Instanzen?

Wenn man jeden Deppenfehler (und die Verwendung einer ungültigen Instanz ist so einer) mit Compilerschaltern ausmerzen könnte, wozu dann noch Programmieren lernen? Wieso entwickelt man nicht gleich einen Compiler, der nicht nur einen Syntaxcheck, sondern auch einen Semantikcheck durchführt?

Gegen Fehler dieser Art empfehle (nicht nur) ich das Einschalten des Switches "Self.Brain" sowie die Einhaltung elementarer Grundregeln. Dann passiert sowas einfach nicht.

[Medium]

So argumentiert könnte man problemlos die Abschaffung moderner IDEs incl. all der netten Helferlein begründen, und mit Notepad schreiben, und den Compiler alles fressen lassen - egal was an Maschinencode dabei nachher raus kommt. Warum sich nicht helfen lassen, wo es möglich ist? Zumindest zur Entwicklungszeit. Zudem sehe ich wenig Zusammenhang zwischen "Programmieren können", und die richtigen Buchstaben so hinschreiben, dass es kompiliert und zur Runtime nicht knallt. Für gewöhnlich denkt der Informatiker in abstrakteren Ebenen, und ist froh, wenn ihm bei so blöden (gern auch aus Flüchtigkeit entstandenen) Patzern auf die Füße getreten wird.
Ich komme ehrlich gesagt nicht ganz dahinter, warum man sich gegen eine solche Option aussprechen wöllte . Ist Bergsteigen mit Seil jetzt auch uncool?