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 :zwinker:

[Luckie]

Du meinst, es müsste eigentlich so heißen:

Delphi-Quellcode:

Pointertyp(pBla)^.Member

[Olli]

Zitat:

Zitat von Luckie

Du meinst, es müsste eigentlich so heißen:

Delphi-Quellcode:

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:

Delphi-Quellcode:

Button1^.Enabled := False;

Fehlermeldung:

Zitat:

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

:gruebel:

[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

Delphi-Quellcode:

  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. :freak:
Sorry Ollie, aber wie hässlich wäre Code, wenn ich jede Objektinstanz erst dereferenzieren müsste? :shock:

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:

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:

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:

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:

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:

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:

Zitat von negaH

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

:shock: ... 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:

Zitat von Robert_G

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

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

Zitat:

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:

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.

[brechi]

Delphi-Quellcode:

Pointertyp(pBla)^.Member

weil man ja nicht unbedingt nur pBla hat

Delphi-Quellcode:

procedure mycopymemory(addr,addr2: pointer; size: cardinal);
var i: cardinal;
begin
  for i := 0 to size-1 do
    pbyte(cardinal(addr)+i)^ := pbyte(cardinal(addr2)+i)^;
end;

das brauch ich für meien vorhaben schon etwas öfter ;)

[jbg]

Zitat:

Zitat von Olli

Zitat:

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.

Ich habe nie behauptet, dass der Text kompiliert. Er steht auch nicht mal in den delphi-Tags. Wenn aber Delphi keine impliziete Dereferenzierung hätte, müsste das so implementiert werden, wie es bereits zu TP Zeiten mit object war.

Zitat:

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

Schon mal auf PPTypeInfo zugegeriffen? Das geht so

Delphi-Quellcode:

S := ti^^.Name;

Würde man nur "ti.Name" schreiben (das kompiliert nicht!), dann wäre das für den Compiler "ti^.Name" was schlicht weg falsch ist und deswegen nicht kompiliert.

Zitat:

Zitat:

Zitat von negaH

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

:shock: ... 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!

Wohl das Wörtchen nicht überlesen? In Assembler hat man nur Zeiger. Da braucht man keine impliziete Dereferenzierung.

Zitat:

Zitat:

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.

Weil er mit deiner Meinung übereinstimmt? Dann muss ich dir wohl in Zukunft auch immer zustimmen, damit ich (fast) immer recht habe. :mrgreen:

[tommie-lie]

Zitat:

Zitat von Olli

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

Damit alle Delphianer auf C rumhacken können, die ja ach so dreckig und umständlich ist, nur weil C einiges genauer macht als Delphi :mrgreen:

[Olli]

Zitat:

Zitat von jbg

Wenn aber Delphi keine impliziete Dereferenzierung hätte

Dies entspricht aber der Syntax, wie sie auch zB C++ verwendet. Dort verhalten sich die normalen Objekte wie Stackvariablen und man greift darauf auch so zu. Erzeugt man ein Objekt dynamisch, so greift man über den Pointer darauf zu. Ist also alles sehr konsistent.

Zitat:

Zitat von jbg

Schon mal auf PPTypeInfo zugegeriffen? Das geht so

Delphi-Quellcode:

S := ti^^.Name;

Würde man nur "ti.Name" schreiben (das kompiliert nicht!), dann wäre das für den Compiler "ti^.Name" was schlicht weg falsch ist und deswegen nicht kompiliert.

Ich benutze zu selten RTTI in Delphi. Ist interessant, aber da haben wir den Punkt. Warum dann nicht konsequenterweise überall diese klare Syntax verwenden?

Zitat:

Zitat von jbg

Wohl das Wörtchen nicht überlesen?

Eigentlich nicht.

Zitat:

Zitat von jbg

In Assembler hat man nur Zeiger.

:shock: Häh ... irgendwie überfordert mich das jetzt, weil du jetzt damit quasi behauptest, daß ich seit Jahren beim Reversen und beim Programmieren alles falsch mache, weil ich schon eine Unterscheidung habe - explizit (offset Bla, [Bla], Bla ...). Bei mir gibt es auch Nicht-Zeiger - und vor allem unterscheiden sich sich Zeiger, Dereferenzierungen usw. in Assembler schon - zumindest in den eigenständigen Assemblern.

Zitat:

Weil er mit deiner Meinung übereinstimmt? Dann muss ich dir wohl in Zukunft auch immer zustimmen, damit ich (fast) immer recht habe. :mrgreen:

So ist es ... :?
Nein, aber ich schätze ihn fachlich und inzwischen auch menschlich, weil er eben ein patenter Mensch ist. Und wenn er mir in so einem Thema beipflichtet, freut mich das natürlich.

[negaH]

Zitat:

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

Zitat:

... 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!

Delphi-Quellcode:

asm
    MOV  EAX,[EDX]
    MOV  EAX,[EDX].Member
end;

In beiden Fällen steht in EDX ein Zeiger, die Derefernzierung erfolgt IMPLIZIT beim Zugriff auf den Zeiger. Der Zugriff auf ein Member eines Records der den Zeiger benötigt erfolgt ohne syntaktisch explizite Dereferenzierung !
Es ist egal ob EDX nun einen Zeiger auf einen allozierten Speicherbereich enthält, oder Self eines Objektes, oder ein stinknormaler Record im Stack ist.

Warum ist es egal ?
Ganz einfach, weil es syntaktisch keine Relevanz für uns hat, es ist uns informell schnuppe, worauf wie da im Moment zugreifen. Wichtig ist doch nur die Zielorientierung in unserer Sprache. Das Ziel ist uns wichtig, nicht der Weg dahin über einen Zeiger oder sonstwas.

Zeiger, Records, Objekt sind Datenkontainer die nach Möglichkeit nur durch und für den Compiler eine Relevanz haben. Wir entscheiden uns bei der Deklaration einmalig für einen dieser Typen damit der Compiler WEIS was WIR von ihm wollen. Aus unserer menschlichen Denksicht heraus ist es uns im Grunde schnuppe, hauptsache es ist laufsicher und effizient, und das sicherzustellen ist Aufgabe des Compilers.
Wir entwicklen immer neuere Sprachen und Compiler die immer mächtiger werden, warum ? Weil wir eben über solch lästiges Beiwerk nicht nachdenken wollen, für uns ist nur das finale Ziel interessant.

Warum gibt es die explizite Derefernzierung in PASCAL mit ^ ?
Ganz einfach, weil es historisch gewachsen ist. Weil bei der Entwicklung jeder Sprache die Entwickler nach links & rechts schauen und Konzepte anderer Sprachen kopierten !
.NET und C# sind doch auch nur abgeschaute Konzepte aus diversen anderen, älteren Sprachen. Wie eben PASCAL Delphi.

Zitat:

Schon mal auf PPTypeInfo zugegeriffen? Das geht so

Delphi-Quellcode:

S := ti^^.Name;

Ja, exakt das ist eine Konsequenz aus der expliziten Derefernzierung, scheußlich das ist (Zitat: Joda).

Denn gäbe es keine solche Dereferenzierungen dann müsste man bei der Sprachsyntax einer Deklaration eines Zeigers auf einen Zeiger ganz andere Schreibweisen einführen. Es macht keinen Sinn einen Zeiger auf einen Zeiger zu deklarieren, dies wird nur jegliche Typsicherheit im Compiler und informationstheoretische Sicherheit beim Lesen eines Source durch einen Menschen, reduzieren.

Gruß Hagen

[tommie-lie]

Zitat:

Zitat von negaH

Delphi-Quellcode:

asm
    MOV  EAX,[EDX]
    MOV  EAX,[EDX].Member
end;

In beiden Fällen steht in EDX ein Zeiger, die Derefernzierung erfolgt IMPLIZIT beim Zugriff auf den Zeiger.

Ich mag mich irren, aber erfolgt der Zugriff nicht explizit durch die eckigen Klammern? Würde stattdessen

Code:

MOV EAX, EDX

stehen, würde die Adresse nach EAX kopiert werden, bei deinem

Code:

MOV EAX, [EDX]

die vier Byte, die an der Speicherstelle stehen, auf die die Adresse in EDX zeigt.

Zitat:

Zitat von negaH

Es ist egal ob EDX nun einen Zeiger auf einen allozierten Speicherbereich enthält, oder Self eines Objektes, oder ein stinknormaler Record im Stack ist.

Ja, weil die beiden letzteren auch nur ein Sonderfall des ersteren sind: ein allozierter Speicherbereich. Der Stack ist in Assembler doch auch nur ein Speicherbereich, auf den das Stackregister zeigt, nur daß ich mit POP* und PUSH* besondere Zugriffsmethoden darauf habe.

[Olli]

Zitat:

Zitat von negaH

Delphi-Quellcode:

asm
    MOV  EAX,[EDX]
    MOV  EAX,[EDX].Member
end;

Alles klar. Dies geht auch beim VC-MASM. Ist nix besonderes, da hier eben nur das Offset dazugerechnet wird. Stattdessen könntest du ja auch nehmen

Delphi-Quellcode:

asm
    MOV  EAX,[EDX]
    MOV  EAX,[EDX+<offset Member>]
end;

... aber das andere ist lesbarer. Ist also nix besonderes und dient auch nicht der Argumentation, weil es aus anderen Gründen so existiert.

Zitat:

Zitat von negaH

Der Zugriff auf ein Member eines Records der den Zeiger benötigt erfolgt ohne syntaktisch explizite Dereferenzierung !

Die eckigen Klammern sind bereits eine Dereferenzierung. Diese spezielle Syntax kann man wie oben gezeigt, auch anders schreiben. Dann wird klarer was gemeint ist. Eine Dereferenzierung enthält der Ausdruck dennoch ;)

Wäre es nicht so, müßte folgender Code durchgehen (was er nicht tut):

Code:

    MOV  EAX, EDX.Member

Zitat:

Zitat von negaH

Ja, exakt das ist eine Konsequenz aus der expliziten Derefernzierung, scheußlich das ist (Zitat: Joda).

:lol:

@tommie-lie: Du weißt, ich gebe dir ungern recht ... hast es dir aber verdient. Die eckigen Klammern sind eben explizite Dereferenzierungen.

BTW: Man kann in Assembler in einem einzelnen Ausdruck nicht mehrere Dereferenzierungen vornehmen ... in Delphi geht dies.

Nachtrag: tommie-lie machte mich gerade darauf aufmerksam, daß vor Member noch ein Typ gehört ;)

[Daniel G]

Zitat:

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.

Luckie, du sprichst mir aus der Seele. Nach einer kurzen Einarbeitungsphase hab' ich C in die Ecke geschmissen, weil ich doch ziemlich frustriert war. Delphi bietet dagegen eine bessere Übersicht, aber die Pointer, wenn es ums übersetzen von C nach Delphi geht, bieten sehr viele Stolpermöglichkeiten.

@Olli: Hat die Frage vielleicht irgendwas mit meinem Problem von gestern zu tun? Das kommt mir so bekannt vor... :zwinker:

[Olli]

Zitat:

Zitat von Daniel G

@Olli: Hat die Frage vielleicht irgendwas mit meinem Problem von gestern zu tun? Das kommt mir so bekannt vor... :zwinker:

Ja, durchaus. Allerdings ist es mir gestern zufällig noch in anderen Posts aufgefallen.

[tommie-lie]

Zitat:

Zitat von Olli

Nachtrag: tommie-lie machte mich gerade darauf aufmerksam, daß vor Member noch ein Typ gehört ;)

Olle Petze! :mrgreen:

[negaH]

Zitat:

Die eckigen Klammern sind bereits eine Dereferenzierung.

Ja, bestreite ich ja garnicht ;) Die Frage ist nur, gibt es einen syntaktischen Unterschied was man dereferenziert ?

Nein, in Assembler dereferenziert man immer Zeiger, dort gibt es nichts anderes. Somit gibt es auch keinerlei Unterscheidungsmerkmale die uns stören könnten. In PASCAL gibt es im Grunde auch nur Zeiger, logisch die CPU arbeitet halt nur mal so und nicht anders.

Wichtig ist doch nur der Unterschied für uns Menschen in informeller Natur. Dieser Unterschied definiert die Leistungsfähigkeit der Programmiersprache. Je abstrakter, sprich unspezifischer, unsere Programmiersprachen werden desto mehr muß der Compiler stupide Arbeit übernehmen, und desto mehr können wir uns bei der Arbeit auf die wirklich relevanten Sachen konzetrieren die keine Maschine wie ein Compiler heutzutage UNS abnehmen kann.
Und das ist die Zielsetzung des Lösens von komplexen Problemen.

Jede Vereinheitlichung in der Syntax die zu einer höheren Abstraktion führen wird ist also exakt der richtige Weg.
Und der Verzicht auf die explizite Dereferenzierung im Source ist genau so ein Schritt zu höherer Abstraktion. Wir bestimmen damit über unsere Programmiersprache das von jetzt an der Compiler UNS die Arbeit mit der expliziten Dereferenzierung abzunehmen hat und somit wird diese Derefernzierung in unseren Augen impliziert !!
Und wieder ist ein unnötiger informeller Schritt in unseren Source ausgemerzt worden.

Schau mal: argumentierst du FÜR die explizite Dereferenzierung so ignorierst du alle neueren Entwicklungen in den Programmiersprachen. Theoretisch müsstest du ausschließlich nur in Assembler, ja sogar nur mit Lochstreifen programmieren wollen.

Irgedwann einmal werden wir so programmieren: "baue eine TCP/IP Verbindung auf und downloade alle notwenigen Dateien". Der Compiler wird dies übersetzen können und dann Additionen, Speicherkopierungen, API Aufrufe, Objekte erzeugen und freigeben, sogar explizit intern Dereferenzierungen durchführen. Also all das was wir heute noch von Hand erledigen müssen. So ein Program bestünde heutzutage noch aus Millionen von Quelltextzeilen, aber in Zukunft wird dem Compiler dafür nur der obige Satz ausreichend sein.
Für uns Menschen bedeutet es aber das wir innerhalb eines gesprochenen, ja eventuell nur gedachten, Satzes exakt die Zielsetzung für die Maschine definieriert haben, mehr wollen wir doch garnicht.

Kannst du nun diese Entwicklung in unserer Arbeit leugnen ??

Ich meine also das die Abschaffung der expliziten Dereferenzierung nur ein klitzekleiner Schritt in die richtige Richtung bei der Evolution unserer Programmeirsprachen ist.
Aus dieser logischen Konzequenz heraus programmiere ich eben, da wor es geht, in Delphi immer mit der impliziten Dereferenzierung.
Aber, grundsätzlich kann das jeder so halten wie er möchte, man muß sich eben immer im klaren sein das man die Zeichen der Zeit so eventuell mißachtet.

Gruß Hagen

[Olli]

Zitat:

Zitat von negaH

Ja, bestreite ich ja garnicht ;) Die Frage ist nur, gibt es einen syntaktischen Unterschied was man dereferenziert ?

Ja, gibt es. Dereferenzieren *immer* mit eckigen Klammern, ansonsten ist es eine Wertübergabe.

Zitat:

Zitat von negaH

Nein, in Assembler dereferenziert man immer Zeiger, dort gibt es nichts anderes.

Das wäre so, wie wenn ich sage, in Assembler gibt es nur Werte, nichts anders. Die Register können als Zahlenwerte oder Zeiger agieren. Genauso ist's mit Speicherwerten. Also irgendwie reden wir aneinander vorbei, denn ob ich's nun Zeiger nenne oder nicht, in Assembler ist es einfach ein Byte, Word oder DWord (oder inzwischen QWord).

Zitat:

Zitat von negaH

Schau mal: argumentierst du FÜR die explizite Dereferenzierung so ignorierst du alle neueren Entwicklungen in den Programmiersprachen.

Einige der neueren Programmiersprachen kennen keine Pointer mehr, bedürfen also nicht der Dereferenzierung. Ich argumentiere also keinesfalls dagegen.

Zitat:

Zitat von negaH

Kannst du nun diese Entwicklung in unserer Arbeit leugnen ??

Nö. Aber genau wie man Interfaces nicht ändert, sollte man solche Ungenauigkeiten in einer Programmiersprache nicht zulassen.

Zitat:

Zitat von negaH

Ich meine also das die Abschaffung der expliziten Dereferenzierung nur ein klitzekleiner Schritt in die richtige Richtung bei der Evolution unserer Programmeirsprachen ist.

Finde ich nicht. Abschaffung von Pointern gern, aber wenn Pointer vorhanden, dann gefälligst auch Dereferenzierung! :mrgreen:

[negaH]

anderes Beipsiel:

Delphi-Quellcode:

type
  ptrData = ^Data;

Hier setzten wir in dem Namen eines Types gleichzeitig auch den Typus dessen mit rein.
Was haben wir gelernt über C/C++ in diesem Falle ?
Warum programmieren wir lieber in PASCAL ohne eine solche Vorgehensweise ?

Ja, ich weiß, es gibt heute noch ähnliche Muster auch in Delphi. Aber es ist wohl unbestitten das diese Unsitte in Delphi bei weitem nicht solche Ausmaße annehmen kann wie in C/C++.

Wir sehen das im Zusammenhang mit der Typsicherheit in Delphi, aber das halte ich für viel zu engstirnig betrachtet. Schaut euch die neueren Sprachen an, dort ist man in diese Richtung noch viel stärker vorangeschritten.

Fazit: Abstraktion ist ein ganz erhebliches Element in der Zukunft der Sprachen. Abstraktion bedeutet aber das immer mehr an Deklarationen, Quelltexten Implikationen enthalten wird. Der Compiler wird also diese Implikationen übersetzen müssenund daraus die informell aufwenigeren expliziten Umsetzungen für UNS selber vornehmen.

Gruß Hagen

[negaH]

@Olli:

Zitat:

Das wäre so, wie wenn ich sage, in Assembler gibt es nur Werte, nichts anders. Die Register können als Zahlenwerte oder Zeiger agieren. Genauso ist's mit Speicherwerten. Also irgendwie reden wir aneinander vorbei, denn ob ich's nun Zeiger nenne oder nicht, in Assembler ist es einfach ein Byte, Word oder DWord (oder inzwischen QWord).

Shit, wenn man mit einem diskutieren muß der die Sprache als Mittel zum Zweck betrachtet ;)

Also: wir reden ja von Dereferenzierungen aus syntaktischer Sicht, und also solches bezog ich mich mit meiner Aussage natürlich nur auf die Syntax in Assebler bei der man diese auch anwendet.

Mir geht es doch nur darum ob die Syntax einheitlich Typeübergreifend ist.
Und die explizite Dereferenzierung in PASCAL steht im Gegensatz zur impliziten Dereferenzierung aller anderen Typen. Die einzigste Ausnahme stellt der Typ Pointer dar.

Betrachtet man dies aus Sicht der Abstraktion so ist es für uns unerheblich welcher Datentyp bei der impliziten Derefernzierung angesprochen wird. Das wäre eben so also ob wir im Namen dieser Variablen immer wieder den Datentyp mit integrieren. Auch dies ist überflüssige Information, zuviel Redundanz.

Gruß Hagen

[Olli]

Zitat:

Zitat von negaH

Delphi-Quellcode:

type
  ptrData = ^Data;

In C wäre dies

Code:

typedef Data *ptrData;

Zitat:

Zitat von negaH

Fazit: Abstraktion ist ein ganz erhebliches Element in der Zukunft der Sprachen. Abstraktion bedeutet aber das immer mehr an Deklarationen, Quelltexten Implikationen enthalten wird.

Das sei dir alles unbenommen. Aber wenn du gestern noch auf einen 14jährigen wettertest, mußt du dich heute fragen lassen, wie du ihm erklärst, daß man den gleichen Sachverhalt verschieden darstellen kann, obwohl die andere Syntax auch noch eine dritte Sache meinen könnte (nämlich komplett ohne Pointer als Scope-Operator).

[tommie-lie]

Zitat:

Zitat von negaH

Delphi-Quellcode:

type
  ptrData = ^Data;

Was haben wir gelernt über C/C++ in diesem Falle ?

Daß wir mit

Code:

typedef SomeType *PSomeType

auch einen typisierten Pointer erhalten? Aber ich bevorzuge eigentlich

Code:

SomeType *blubb

und habe dann mit blubb einen Pointer, der zumindest in C++ ebenso "sicher" ist, wie in DelphiLanguage, eine Dereferenzierung mit *blubb bringt mich zurück zum Typ SomeType mit allen seinen Members, unabhängig davon was ich vorher in blubb für einen Käse reingeschrieben habe. Exakt genauso verhält sich ein ^Data-Pointer in Delphi. Übrigens kann ich sowohl in C, als auch in Delphi einen derartigen Pointer in einen anderen Pointer-Typ casten und dereferenzieren. Dann lande ich nochmal woanders. Das ist das schöne an Pointer :mrgreen:

Zitat:

Zitat von negaH

Warum programmieren wir lieber in PASCAL ohne eine solche Vorgehensweise ?

Weiß nicht, ich persönlich habe C++ und C# lieb gewonnen und programmiere nicht lieber in Pascal-artigen Sprachen? Und du?

Zitat:

Zitat von negaH

Der Compiler wird also diese Implikationen übersetzen müssenund daraus die informell aufwenigeren expliziten Umsetzungen für UNS selber vornehmen.

Schön und gut, da hat niemand in diesem Thread etwas gegen gesagt. Aber Es gibt hier in Delphi eindeutig eine Mehrdeutigkeit mit der gleichen oder verschiedenen Bedeutungen.


Edit: Mist, zu langsam...

[negaH]

Zitat:

Aber Es gibt hier in Delphi eindeutig eine Mehrdeutigkeit mit der gleichen oder verschiedenen Bedeutungen.

Ja, und welche dieser Deutigkeiten nun die Richtigere ist, das ist der Streitpunkt.

Zitat:

und habe dann mit blubb einen Pointer, der zumindest in C++ ebenso "sicher" ist, wie in DelphiLanguage, eine Dereferenzierung mit *blubb bringt mich zurück zum Typ SomeType mit allen seinen Members, unabhängig davon was ich vorher in blubb für einen Käse reingeschrieben habe.

Ah, also doch exakt meine Argumentation. Bei der Benutzung dieses neuen Types ist es dir wurscht was für ein Basistyp dahinterliegt. Möchtest du es aber genau wissen dann, wie du so schön sagtest, "bringt es mich zurück zum SomeType". Also zur eigentlichen Deklaration in der Schnittstelle zu deinem Source !

Das IST Abstraktion. Einmalig definierst du diesen Typ damit der Compiler WEIS was er damit machen soll. Und im restlichen Source arbeitest DU auf diesen abstrakteren Typ, weil es für UNS den Source lesbarer macht.

Zitat:

Exakt genauso verhält sich ein ^Data-Pointer in Delphi

Ja, aber eben nicht mehr bei der Benutzung im restlichen Source falls man diesen ständig dereferenziert.

Mein Meinung das ist !

Gruß Hagen

[Olli]

Zitat:

Zitat von negaH

Ja, und welche dieser Deutigkeiten nun die Richtigere ist, das ist der Streitpunkt.

Die eineindeutige Variante, wie dein Mathematiker sagen würde ;)

Zitat:

Zitat von negaH

Mein Meinung das ist !

Na die lassen wir dir dann mal! :mrgreen:

[negaH]

Zitat:

Die eineindeutige Variante, wie dein Mathematiker sagen würde

Hm, ich meine die rein informelle Variante, die eben immer redundant und mehrdeutig sein wird. Der zukünftige Compiler wird dann Stück für Stück alle fehlenden Informationen abfragen, und wir werden darauf antworten. So als wäre es eine Diskussion. Innerhalb dieser Diskussion wird aber der Compiler immer alle Möglichkeiten aufzählen so das wir uns dem gesetzen Ziel immer weiter nähern.

Und schon heute erachte ich die Fehlermeldungen und Warnungen des Compilers für eine solche "Diskussion", nur eben ohne "intelligente" Vorschläge des Compilers.

Vertrackte Argumentation mit dem Mathematiker die du da führst. Denn Mathematiker denken infinitiv und exakt diese Denkweise ist widersprüchlich zu einem Informatiker. Viele Aussagen der Mathematiker sind also eineindeutig und infinitiv richtig, aber finitiv und praktisch betrachtet nicht realisierbar. Ein Ingeneur, wie wir es welche sind, kann öfters mit solchen Aussagen leider nichts anfangen.

Aus meiner Sicht hast du mit dieser Argumentation exakt in meine Richtung gearbeitet ;)

Gruß Hagen

[tommie-lie]

Zitat:

Zitat von negaH

Ja, und welche dieser Deutigkeiten nun die Richtigere ist, das ist der Streitpunkt.

Ich bin der Meinung, daß die konsistentere die richtigere sei: Pointer haben dereferenziert zu werden. Alles andere ist kontextabhängig und in meinen Augen nur unnötig verwirrend.

Zitat:

Ah, also doch exakt meine Argumentation. Bei der Benutzung dieses neuen Types ist es dir wurscht was für ein Basistyp dahinterliegt.

Stimmt.

Delphi-Quellcode:

type
  PBlah = ^TBlah;
  TBlah = record
    Member1: LongInt;
  end;

type
  PBlubb = ^TBlubb;
  TBlubb = record
    Member2: ShortInt;
  end;

var
  SomeBlubb: PBlubb;
  SomeOtherBlubb: TBlubb;
begin
  SomeOtherBlubb.Member2 := 5;
  SomeBlubb := @SomeOtherBlubb;
  PBlah(SomeBlubb)^.Member1 := 5;
end;

Habe ich jetzt einen LongInt oder einen ShortInt geschrieben? Du siehst, auch unter Delphi ist es mir wurscht, was für ein Typ dahintersteckt. Es gibt da keinen Unterschied zwischen C und Pascal, ich weiß also nicht, welche "Unsitte" du meinst, die in Delphi nicht solche Ausmaße hätte.

Zitat:

Zitat von negaH

Das IST Abstraktion. Einmalig definierst du diesen Typ damit der Compiler WEIS was er damit machen soll. Und im restlichen Source arbeitest DU auf diesen abstrakteren Typ, weil es für UNS den Source lesbarer macht.

Ich weiß, was Abstraktion ist. Deswegen kann ich doch trotzdem eindeutige Regeln befolgen und Pointer dereferenzieren, wie es sich gehört.

[negaH]

Zitat:

Du siehst, auch unter Delphi ist es mir wurscht, was für ein Typ dahintersteckt.

Und warum derefernezierst du diesen dann beim Zugriff auf ein Member ?
Ist doch im grunde egal und enthält keine zusätzlich wertvollen Informationen die den Source lesbarer für uns Menschen macht.

DU dereferenzierst diesen nur aus Prinzip, aus einer für dich sinnvollen Vereinbarung, Festlegung.
Ist diese Festlegung wirklich sinnvoll ?

Gruß Hagen

[tommie-lie]

Zitat:

Zitat von negaH

DU dereferenzierst diesen nur aus Prinzip, aus einer für dich sinnvollen Vereinbarung, Festlegung.
Ist diese Festlegung wirklich sinnvoll ?

Okay, ich verändere meinen Code ein wenig:

Delphi-Quellcode:

type
  PBlah = ^TBlah;
  TBlah = record
    Member: LongInt;
  end;

type
  PBlubb = ^TBlubb;
  TBlubb = record
    Member: ShortInt;
  end;

function DoSomething(aBlubb: TBlubb): PBlah;
begin
  Result := @aBlubb;
end;

// imagine 20 pages of other code here

var
  SomeBlubb: TBlubb;
begin
  SomeBlubb.Member := 5;
  DoSomething(SomeBlubb).Member := 42;
end;

Weißt du jetzt noch, ohne 20 Seiten nach oben zu scrollen, in was für eine Datestruktur ich 42 schreibe ob ich 42 in einen dereferenzierten Pointer schreibe, oder nicht?

[negaH]

Zitat:

Weißt du jetzt noch, ohne 20 Seiten nach oben zu scrollen, in was für eine Datestruktur ich 42 schreibe ob ich 42 in einen dereferenzierten Pointer schreibe, oder nicht?

Delphi-Quellcode:

 DoSomething(SomeBlubb).Member := 42;

Warum sollte mich das in obiger Zeile interessieren ? Ich möchte doch nur 42 abspeichern.
Der Rest, sprich wie und wo und ob typsicher das ist doch Aufgabe des Compilers.

Gruß Hagen