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

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