Warum läßt Delphi das zu: Pointertyp(pBla).Member???

[Olli]

Wes Grundes läßt der Delphicompiler solchen Schund zu, ohne daß der Pointertyp explizit dereferenziert werden muß? Ich finde sowas widerlich, weil es die Syntax ungenau macht. Schlimmer noch, warum greift die Seuche um sich und benutzen die Delphianer diese ungenaue Syntax?

Los, macht mich fertig

[Luckie]

Du meinst, es müsste eigentlich so heißen:
Pointertyp(pBla)^.Member

[Olli]

Zitat von Luckie:

Du meinst, es müsste eigentlich so heißen:
Pointertyp(pBla)^.Member

Exakt - das meine ich.

[jbg]

Nichts hindert dich das so zu schreiben.

Aber es wäre doch ziemlich lästig wenn man laufend Form1^.ShowModal; Button1^.Enabled := False; ... schreiben müsste. Und außerdem ermöglicht das eine leichtere Portierung nach .NET.

[Luckie]

Wenn es diese Art Compilermagic nicht geben würde, würde kein Hahn da anch krähen und es so akzeptieren. In anderen Sprachen ist es ja auch nicht anders. Die explizite Dereferenzieruzng hat eiegntlich den Vorteil, dass man genau sieht, wann man es mit einem Zeiger zu tun hat und, wann nicht. Gerade bei Delphi Anfängern führt das zu Verständnisproblemen, denke ich.

Übrigens gerade probiert:
Button1^.Enabled := False; Fehlermeldung:

Zitat:

[Error] Unit1.pas(28): Pointer type required

[negaH]

Zitat:

Schlimmer noch, warum greift die Seuche um sich und benutzen die Delphianer diese ungenaue Syntax?

Ich mache es immer so seitdem es Delphi zulässt. Damals war ich einer der ersten die diese Schreibweise verlangt haben.

Warum ?

Weil die Schreibweise

Delphi-Quellcode:

  
  Pointer^.Member

exakt die gleiche Funktionalität erzwingt wie

  Pointer.Member Also warum sollte man es dann nicht auch vereinheitlichen bzw. abkürzen ?

Oder anders ausgedrückt: das Ziel ist das Gleiche, die basierende Typinformation ist irrelevant für den Leser des Sources, denn um die Typsicherheit soll sich gefälligst der Compiler in meinem Auftrag kümmern.
Es ist mir echt schnuppe in diesem Moment ob ein Pointer auf einen Record oder ein simpler Record oder ein Objekt oder sonstwas angesprochen wird, hauptsache ich greife auf das richtige Member mit der richtigen Methode zu.
Die explizite Dereferenzierung ist also nur ein unnötig störendes Element in einem Source der inhaltlich keinerlei Mehrinformation zum Verständnis in diesem Moment der Quellttextzeile bietet. Dafür sind ja die separaten Typdeklartionen zuständig.

Und, falls du dich entschließen solltes eines Tages deinen Pointer auf Record in einen Record im Stack oder in eine Klasse zu verwandeln, dann ist die neue Schreibweise kompatibel ohne Änderungen !

Übrigens, in Assembler kennt man syntaktisch diesen Unterschied ebenfalls nicht.

Gruß Hagen

[Robert_G]

Ich halte das jetzt für eine Scherzfrage mit halbernsten Hintergrund.
Sorry Ollie, aber wie hässlich wäre Code, wenn ich jede Objektinstanz erst dereferenzieren müsste?

Was ich nicht kapiere ist, dass der Delphicompiler (und die RTL) keine Typensicherheit erzwingt.
Warum kann ich das machen:

Delphi-Quellcode:

var
   someInt : Integer;
begin
   TObject(someInt) := TObject.Create();
   dec(someInt);
   TObject(someInt).Free();

Das ist doch geradezu widerlich...
Typensicherheit heißt für mich, dass eine Instsnz von TSomeType auch wirklich das ist, was sie mir vorgaukelt.

[jbg]

Zitat von Robert_G:

Das ist doch geradezu widerlich...

Weil es Zeiger und Typecast Spielchen sind. Die C/C++ Bevölkerung kennst sich da bestens aus.

Zitat:

Typensicherheit heißt für mich, dass eine Instsnz von TSomeType auch wirklich das ist, was sie mir vorgaukelt.

Ab .NET hast du das Problem ja nicht mehr. Da bekommst du entweder nil oder eine Exception.

[Robert Marquardt]

Warum es in C und C++ eingefuehrt wurde verstehe ich nicht, denn dort gibt es den -> Operator.
Bei Delphi macht das ja Sinn. Besonders fuer Member einer Klasse, da eine Klassenreferenz formal kein Zeiger ist.
Die Klassenreferenz ist nur als Zeiger implementiert.
Das es fuer alle Zeiger geht, liegt an der Art wie die Zeiger von C (besonders PChar) in Delphi eingepasst wurden.
Es ist also weniger ein neu eingefuehrtes Feature wie bei C++ sondern eher ein notwendiges Uebel der Kompatibilitaet zu C.

[Olli]

Zitat von Luckie:

Die explizite Dereferenzieruzng hat eiegntlich den Vorteil, dass man genau sieht, wann man es mit einem Zeiger zu tun hat und, wann nicht. Gerade bei Delphi Anfängern führt das zu Verständnisproblemen, denke ich.

Eben!

Zitat von Luckie:

Übrigens gerade probiert:
[...]

Weil jbg hier die interne Verwaltung damit verwechselt, daß nach außen Objekte sowas wie Records sind und nur intern über ihren Zeiger verwaltet werden.

Zitat von negaH:

Die explizite Dereferenzierung ist also nur ein unnötig störendes Element in einem Source der inhaltlich keinerlei Mehrinformation zum Verständnis in diesem Moment der Quellttextzeile bietet. Dafür sind ja die separaten Typdeklartionen zuständig.

Es dürfte aber Fälle geben, wo dies zu Problemen führt, wenn nicht ein expliziter Cast angefügt wird. Und dann ist's egal ob ich einen Cast oder lieber eine Dereferenzierung nehme.

Aber Gegenfrage: Warum gibt's das überhaupt, wenn ich es doch auch ohne ^ schreiben kann?

Zitat von negaH:

Und, falls du dich entschließen solltes eines Tages deinen Pointer auf Record in einen Record im Stack oder in eine Klasse zu verwandeln, dann ist die neue Schreibweise kompatibel ohne Änderungen !

Wohl wahr ... das wäre ein Vorteil.

Zitat von negaH:

Übrigens, in Assembler kennt man syntaktisch diesen Unterschied ebenfalls nicht.

... gib mal ein Beispiel. Das wäre mir total neu. Daß der BASM diverse Syntaxschweinereien zuläßt, ist mir bekannt ... in anderen Assemblern kannst du vieles aber nicht so machen!

Zitat von Robert_G:

Sorry Ollie, aber wie hässlich wäre Code, wenn ich jede Objektinstanz erst dereferenzieren müsste?

Wußte garnicht, daß du *nur* mit Objektpointern arbeitest ...

Zitat von Robert_G:

Das ist doch geradezu widerlich...
Typensicherheit heißt für mich, dass eine Instsnz von TSomeType auch wirklich das ist, was sie mir vorgaukelt.

Gerade hier bringst du doch ein Beispiel mit einem Objektpointer. Und Pointer sind nunmal nix weiter als Zahlen ...

Zitat von Robert Marquardt:

Besonders fuer Member einer Klasse, da eine Klassenreferenz formal kein Zeiger ist.
Die Klassenreferenz ist nur als Zeiger implementiert.

Hört auf Robert! Der hat (fast <- sorry!) immer recht.