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

[himitsu]

Zitat:

Zitat von Delphi-Laie (Beitrag 1172023)

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


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

Delphi-Quellcode:

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

if not a = b and c then

Man muß nur die Rangfolge beachten :zwinker:



[edit]

Zitat:

Zitat von Gausi (Beitrag 1172027)

Aus

Delphi-Quellcode:

if a = b and c = d then

wird also zuerst ein

Delphi-Quellcode:

if a = e = d then

Vorher wird daraus erstmal ein

Delphi-Quellcode:

if a = (b and c) = d then

:angle:

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. :mrgreen:
Bei

Delphi-Quellcode:

if a = b and c then

, aka

Delphi-Quellcode:

if a = (b and c) then

, würde es anders aussehn, da es eben nicht zu

Delphi-Quellcode:

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.

[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 :)

[p80286]

Zitat:

Zitat von Delphi-Laie (Beitrag 1171169)

Die Variablen bekommen dann regelmäßig ihre Initialisierung, kann mir aber den Grund dazu als Kommentar daneben niederzurschreiben nie verkneifen.

Ist wohl eine Frage des Alters, Alle Variablen sind zu initialisieren!

Da mach ich mir keine Gedanken mehr darüber ob denn bei welcher Bedingung aber nur wenn ausgenommen.....
Wenn result ein -1 hat und nur 0 oder 1 kommen dürften, dann sitzt der Fehler wieder mal vor der Tastatur.

Gruß
K-H

[Iwo Asnet]

Ich finde die Klammern auch blöd. *Warum* sie da sind, ist klar: "Liegt an der Grammatik". Trotzdem sind sie blöd.

Zitat:

Zitat von Delphi-Laie (Beitrag 1172023)

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.

Dann vereinfache doch enfach die Ausdrücke. Wenn ich mehr als 3 Sekunden brauche, um einen Ausdruck zu verstehen oder auch nur einmal strauchele, wird das vereinfacht.

Was mich nämlich nervt, sind Programmzeilen wie

Delphi-Quellcode:

If Not Foo.Busy or Not Bar.Error and (Not (Foo.Value>xyz) and (Bar.Stuff<Foo.Bar) and InHeaven.IsYearMarket) then

Damit verbringe ich Stunden, nämlich um den Code überhaupt zu verstehen.
Dann soll man gefälligst durch Refaktorisierung eben umformen:

Delphi-Quellcode:

If MembersAreCompatible(Foo,Bar)and InHeaven.IsYearMarket) then

Das ist lesbar. Wer wissen will, wie "MembersAreCompatible" funktioniert, kann ja nachschauen:

Delphi-Quellcode:

Function MembersAreCompatible(A :TFoo; B:TBar) : Boolean;
Begin
  Result := Not A.Busy or Not B.Error and (Not (A.Value>xyz) and (B.Stuff<A.Bar);
End;

Aber für das Verständnis der eigentlichen IF-Abfrage ist das unerheblich. Außerdem ist der Code dann dokumentiert und wer die Kompatibilität von Mitgliedern genauer spezifizieren möchte, der weiss genau, wo er ansetzen muss ('Steht ja da');

[Jumpy]

Blitzeinschlag in der Nachbarschaft. Der Serverraum hat eine USV aber die popligen Entwickler-PCs nicht. Es waren auch scheinbar nicht alle Phasen betroffen, in manchen Räumen sind die Lichter und PCs angeblieben. Aber mich hat's zerissen :(. Zum Glück erst vor 20 min. gespeichert.

[Delphi-Laie]

Der Codeexplorer ist ja eine feine Sache, wenn man mit vielen Unterprogrammen, die keine Ereignisbehandlungsroutinen sind, zu tun hat.

Aber kennt Ihr das auch, daß er "abstürzt"? In meinem Delphi 4 passiert es dann und wann, nach einer Weile (Systematik bzw. Ursache noch nicht gefunden), daß er unbedienbar wird. Er regiert zwar noch, wenn ich verschiedene Units entsprechend dem Klick auf ihre Reiter wähle, und erzeugt dann neuen, an die Unit angepaßten Inhalt, doch Klicks auf die Baumknoten ("Treenodes") ignoriert er beharrlich, ist dann also leider wertlos.

[jaenicke]

Zitat:

Zitat von Delphi-Laie (Beitrag 1173006)

Aber kennt Ihr das auch, daß er "abstürzt"? In meinem Delphi 4 passiert es dann und wann, nach einer Weile (Systematik bzw. Ursache noch nicht gefunden), daß er unbedienbar wird.

Das kenne ich weder aus Delphi 5 noch aus aktuellen Versionen, nein. Delphi 4 ist neben Delphi 2 eine der beiden Versionen, die ich noch nie in den Fingern hatte. Wobei die ja (vor allem pur ohne Update) ohnehin als eine der schlimmsten Versionen neben Delphi 2005 gilt was Bugs angeht, insofern war ich da auch nicht scharf drauf. :wink: