Was nervt euch so, während der Programmierung oder so allgemein

[Delphi-Laie]

Mich stört, daß man generell mehr als nötig schreiben muß. Damit meine ich aber nicht die Schlüsselwörter Begin und end statt der beiden Klammern in C & Konsorten, das ist ein Klacks. Ich bin auch kein Freund extrem komprimierter Anweisungen in C & Co. (in denen mehr als eine Sache (fast) gleichzeitig passiert), obwohl das Lesen derselben letztlich auch nur eine Übungsangelegenheit ist.

Nein, es geht um etwas anderes. In C & Co. muß man logische Ausdrücke ja einklammern: if (a=b) then... . Wie schön, daß man darauf in Pascal verzichten kann. Nur, warum man mit den Einklammern beginnen muß, wenn man mehr als einen zu verarbeitenden Audruck hat und diese miteinander verknüpfen muß, also z.B. if (a=b) and {oder or} (c=d) then..., erschließt sich mir bis heute nicht. Soll das ein zusätzlicher Zwang zur Übersichtlichkeit sein? Ich weiß nicht, wieviel Zeit mir während meines Programmierens verlorenging, nur, um nicht logische Fehler in den Boolschen Ausdrücken an sich, sondern in deren (m.E. unnötig aufgezwungener) Klammerlogik aufzuspüren.

[Bummi]

Delphi-Quellcode:

var
 a,b,c:variant;
 d:Variant;
begin
  a := 1;
  b := 2;
  c := 3;
  d := a=(b or c);
  Showmessage(d);
  D := (a = b) or c;
  Showmessage(d);
  D := a = b or c;
  Showmessage(d);
end;

[Gausi]

Naja, AND ist nicht nur ein boolscher Operator, sondern auch ein bitweises AND. Und in der Prioritätenliste kommen diese Operatoren vor den Vergleichsoperatoren (was generell sinnvoll ist, wie ich finde).

Aus if a=b and c=d then wird also zuerst ein if a = e = d then , und daraus ein if (Bool) = d then . Und das schmeckt einer typentreuen Sprache wie Delphi nicht so gut (wenn a,b,c,d Integer o.Ä. sind). Daher muss man bei sowas klammern.

[Memnarch]

Genau, das liegt an der operator-bindung. Vergleichbar wie +- und */
Hab nen MiniCompiler für Pascal ähnlicher syntax geschrieben. Das klammern muss ich genauso machen für Bedingungen.

zusätzlich resultiert die Klammerpflicht aus der sprachdefinition.

a = b

ist eine <relation> und steht (ganz) oben im parser baum. AND steht an selber stelle wie */ und gehört damit zu einem <term>. Grob gesehen baut die strultur wie bei pascal folgendermaßen aufeinander auf:

<relation> ::= <expression> [<relop> <expression>]
<expression> ::= <term> [<addop> <term>]*
<term> ::= <signed factor> [<mulop> factor]*
<signed factor> ::= [<addop>] <factor>
<factor> ::= <integer> | <variable> | (<Relation>)

bereiche in [] sind optional. Mit * gekenzeichnet bedeutet dass der bereich beliebig oft wiederholt werden darf.

Und da stoßen wir schon auf den grund:
Relation erlaubt nur eine Relation-operation und dann ist schluss. Danach erwartet der Parser nichts mehr. Machen wir eine relation in () ergibt sich folgendes:

Der Parser fängt bei der Relation-Ebene an und fällt durch bis unten auf den Factor wo durch | erlaubte möglichkeiten gegeben sind. Und da finden wir dan unsere Relation in klammern wieder.

Da die daraus erstellte struktur(man stelle sich einen baum vor) von unten nach oben resolved wird, wird (<Relation>) priorisiert und erst DANACH gelangen wir weiter oben auf die <term> ebene.

Es ist anzumerken das sich hierbei an Pascal orientiert wird. Wie weit diese struktur mit Delphi oder komplettem Pascal übereinstimmt ist eine andere Frage. Aber die Wurzeln des Grundes lassen sich denke ich so gut erkennen

Quelle:
http://compilers.iecc.com/crenshaw/
http://compilers.iecc.com/crenshaw/tutor6.txt

[himitsu]

gefunden
http://docwiki.embarcadero.com/RADSt...e_%28Delphi%29

[Memnarch]

@Himitsu: ah danke, die seite habe ich nicht mehr gefunden

[himitsu]

Zitat von Delphi-Laie:

z.B. if (a=b) and {oder or} (c=d) then..., erschließt sich mir bis heute nicht.

Das ist ganz einfach.

Es gibt eine Reihenfolge/Rangfolge der Verarbeitung, bzw. die Operatoren haben unterschiedliche Prioritäten.

http://de.wikibooks.org/wiki/Program...al:_Operatoren
siehe Rangfolge der Operatoren
[edit]Das unäre + und - wurde in der Liste nicht mit aufgenommen, also das Vorzeichen einer Zahl, aber diese kann man sich auch gerne an Position 0 vorstellen, noch vor dem NOT.[/edit]

Das steh zwar auch nochmal in der OH, aber solche Einträge findet man dort nicht so einfach


Ich weiß nicht was du hast ... es geht doch? Man kann Klammern weglassen.

Delphi-Quellcode:

if ((not a) = (b and c)) then

if not a = b and c then

Man muß nur die Rangfolge beachten



[edit]

Zitat von Gausi:

Aus if a = b and c = d then wird also zuerst ein if a = e = d then

Vorher wird daraus erstmal ein if a = (b and c) = d then

Praktisch ist aber, daß man nur ein = haben kann, innerhalb eines Auswertungspfades. Manchmal aber auch unpraktisch, aber hier praktisch, da man so eine Fehlermeldung bekommt.
Bei if a = b and c then , aka if a = (b and c) then , würde es anders aussehn, da es eben nicht zu if (a = b) and c then wird.

[Delphi-Laie]

Wenn man die Klammern weglassen muß, dann muß man umformen. Mag sein, daß der Compiler es intern so vereinfacht (hineinprogrammierte Intelligenz), ich bin jedoch kein Compiler. Lenkt ab, muß man sich zusätzlich hineindenken. Lohnt sich dafür m.E. nicht.

Erklärlich ist es nur insofern, als daß die logischen Ausdrücke and, or und xor (vollständig?) eine höhere Priorität als die Vergleichsoperatoren haben, aber das weiß ich aus dem Stegreif nicht. Dann müssen die Klammern natürlich gesetzt werden.