If ...else - Abfrage mit Tücken

[geesmith]

Hallo zusammen

Es geht um eine If-Abfrage mit mehr als einem Check drin welche mit AND verbunden sind. Konkret um eine If-Afrage mit zwei Checks.

Ich habe mit Delphi 2009 folgenden Code geschrieben:

Delphi-Quellcode:

  if (FBITechEntryActive <> nil) and (FBITechEntryActive.AN8 <> cxCurrencyEdit_AN8.Value) then
  begin
    DoSomething;

Also wenn ein Objekt nicht nil ist, dann soll er eben von diesem Objekt noch den Wert mit einem anderen Wert vergleichen.

Diese Abfrage lief mal problemlos. Ich ging damals davon aus, dass Delphi erst den ersten Check macht und falls dieser nicht zutrifft der zweite Check gar nicht mehr ausführt. Dass dies fehlerfrei lief gab mir eigentlich recht... dachte ich.

Mittlerweile programmiere ich mit Delphi XE5 und plötzlich bekomme ich mit obigen Code eine Schutzverletzung, so dass ich den Code wie folgt umschreiben musste:

Delphi-Quellcode:

  if (FBITechEntryActive <> nil) then
  begin
    if FBITechEntryActive.AN8 <> cxCurrencyEdit_AN8.Value then
      DoSomething;

Es scheint, als ob er bei der ersten Abfrage den Vergleich "(FBITechEntryActive.AN8 <> cxCurrencyEdit_AN8.Value)" gemacht hat.

Nun meine Frage... wäre die If-Abfrage wie ganz oben eigentlich ok? Oder sollte sowas gar nicht erst gemacht werden?

[mkinzler]

Ist die vollständige Boolean Auswertung aktiviert?
http://docwiki.embarcadero.com/RADSt...r-Direktive%29

[Sir Rufo]

Das ist eine Option die man einstellen kann, ob der gesamte Ausdruck ausgewertet wird oder nur bis zum eindeutigen Ergebnis.

[Helmi]

oder unter "Projekte --> Delphi-Compiler --> Compilieren"

[DeddyH]

Wenn man die AND-Verknüpfung durch versxhachtelte If-Abfragen ersetzt, spielt diese Einstellung keine Rolle.

[Der schöne Günther]

Interessant- Ich hatte neulich auch ein älteres Projekt in XE5 importiert und die vollständige Boolsche Auswertung war auch aktiviert. Ob da beim Konvertieren was falsch läuft?

[Captnemo]

Lieber 2 If-Anweisungen als nur eine mit Eigenschaften eines Objects, das evtl. gar nicht vorhanden ist. Damit schießt man sich im Zweifelsfall nur in's Knie.
Mag zwar sein, dass es mit der entsprechenden Compileranweisung funktioniert, aber wenn man sich sowas angewöhnt, und in großen Projekten öfter macht....
ich würd sowas lieber generell nicht machen.

[geesmith]

Super, Danke für eure Antworten. Jetzt bin ich gscheiter. :)

[himitsu]

Zitat:

Zitat von Captnemo (Beitrag 1276074)

Mag zwar sein, dass es mit der entsprechenden Compileranweisung funktioniert,

Lieber doppelten Code?

Die vollständige boolische Auswertung ist ein Sonderfall und nicht der Standard.
Wenn man auch für Standardsachen überall Spezialbehandlungen einführt, dann wird die Arbeit schnell umfangreich und unnötig schwierig.

Delphi-Quellcode:

// besser niemals so
if Assigned(obj) and obj.IsActive then begin
  obj.MethodeA;
  obj.MethodeB;
  obj.MethodeC;
end;

// sondern so
if Assigned(obj) then
  if obj.IsActive then
    try
      if Assigned(obj) then
        obj.MethodeA;
    except
      ShowMessage('unnötige sinnlose Fehlermeldung, welche die originale Exception verschrottet');
    end;
if Assigned(obj) then
  if obj.IsActive then
    try
      if Assigned(obj) then
        obj.MethodeB;
    except
      ShowMessage('es könnte ja sein daß Exception-Objekt verschwindet');
    end;
if Assigned(obj) then
  if obj.IsActive then
    try
      if Assigned(obj) then
        obj.MethodeC;
    except
      ShowMessage('also besser nicht verwenden');
    end;

Es könnte ja sein das Objekt verschwindet zwischendurch. :roll:



Die Projektoptionen sind an einigen Stellen eh voll schrottig.
* solche Optionen haben global dort eigentlich nichts zu suchen (wenn man das benötigt, dann sollte man das ausschließlich lokal dort aktivieren, wo nötig)
* die Standardvorgaben sind teilweise auch Mist. (standardmäßig aktivierte Debug-DCUs :wall:)
* und eine Vorlage für neue Projekte kann man dort auch nicht mehr speichern.

[mm1256]

Ich aktiviere die vollständige boolsche Auswertung aus og. Gründen auch nicht, sondern setze die Ausdrücke in Klammer und hatte noch nie Probleme damit:

Code:

 if ((FBITechEntryActive <> nil) and (FBITechEntryActive.AN8 <> cxCurrencyEdit_AN8.Value)) then
  begin
    DoSomething;

[DeddyH]

Was soll die zusätzliche Klammerung bei nur 2 Audrücken denn bringen?

[jaenicke]

Wenn für einen bestimmten Code eine bestimmte Einstellung der vollständigen boolschen Auswertung in die eine oder andere Richtung notwendig ist, dann aktiviere ich diese auch direkt davor oder deaktiviere sie (Direktive BOOLEVAL ON bzw. OFF). Auf diese Weise ist stets sichergestellt, dass der Code immer zuverlässig funktioniert egal in welchem Projekt mit welcher globalen Einstellung er benutzt wird.
Dazu kommt natürlich noch ein kurzer Kommentar warum das notwendig ist.

So braucht man auch keine Schachtelung stattdessen, die ggf. das ganze unübersichtlicher machen kann. Zudem fehlt dann die Möglichkeit ein gemeinsames else zu nutzen, so dass ggf. zusätzlicher und oft redundanter Code notwendig ist.

Zitat:

Zitat von mm1256 (Beitrag 1276114)

Ich aktiviere die vollständige boolsche Auswertung aus og. Gründen auch nicht, sondern setze die Ausdrücke in Klammer

Wenn du Pech hast, stolperst du dabei über einen Compilerfehler. Ich hatte mal den kuriosen Fall, dass eine überflüssige Klammerung dazu führte, dass der erzeugte Code falsch war. Leider hatte ich das damals aus Zeitmangel nicht dokumentiert oder gemeldet, so dass ich nicht prüfen kann, ob der Fehler in aktuellen Versionen noch besteht.

[Sir Rufo]

@jaenicke :thumb:

[himitsu]

Zitat:

Zitat von mm1256 (Beitrag 1276114)

Ich aktiviere die vollständige boolsche Auswertung aus og. Gründen auch nicht, sondern setze die Ausdrücke in Klammer und hatte noch nie Probleme damit:

Code:

 if ((FBITechEntryActive <> nil) and (FBITechEntryActive.AN8 <> cxCurrencyEdit_AN8.Value)) then
  begin
    DoSomething;

Das Klammersetzen hat hiermit absolut nichts zu tun.

Die "vollständige boolische Auswertung" bedeutet, daß alle Vergleiche geprüft werden, egal ob das Endergebnis bereits fest steht.
Kann man benutzten, wenn alle Funktionsaufrufe in dem "boolischen Ausdruck" ausgeführt werden müssen/sollen.

Bei

Delphi-Quellcode:

False and Irgendwas

ist mit False das Ergebnis bereits festgelegt und man muß garnicht erst gucken was Irgendwas macht.
Wäre Irgendwas eine Funktion oder Referenzauflösung, dann würde dieses nicht mehr ausgeführt, außer wenn man diese Option aktiviert hat.
Dann würde das zwar noch ausgeführt, auch wenn es auf das Ergebnis des boolischen Ausdrucks keinen Einfluss mehr hat.

[p80286]

Zitat:

Zitat von Der schöne Günther (Beitrag 1276070)

Interessant- Ich hatte neulich auch ein älteres Projekt in XE5 importiert und die vollständige Boolsche Auswertung war auch aktiviert. Ob da beim Konvertieren was falsch läuft?

Da hat wohl jemand aus uralten TP-Zeiten was übernommen:evil:
Diese Verhalten ist mir allerdings auch schon über den Weg gelaufen, und es gab keine Compileranweisungen!

Gruß
K-H