Mehrere IFDEF und ELSE hintereinander

[DieDolly]

Wie schreibt man eigentlich mehrere IFDEF und ELSE hintereinander? Ich habe die markierte Zeile hinzugefügt (gerade ist die kommentiert) und seitdem ist die Bedingung angeblich nicht geschlossen.

Delphi-Quellcode:

{$IFDEF CONDITION_0}

  A: string = //
  {$IFDEF IS_A} 'A' {$ELSE} //
  {$IFDEF IS_B} 'B' {$ELSE} //
  {$IFDEF IS_C} 'C' {$ELSE} //
   'ELSE' {$ENDIF} //
  {$ENDIF};

{$ENDIF}

Die dazugehörige inc-Datei

Delphi-Quellcode:

{$DEFINE CONDITION_0}
// {$DEFINE IS_A}
// {$DEFINE IS_B}
{$DEFINE IS_C}

Es sollte also eigentlich "C" in der Variable A stehen.

[Andreas13]

Z.B. so:

Delphi-Quellcode:

  {$ifdef VER1}
    {$undef  J_OPT}
    {$ifndef VER1_0}
      {FPC 1.9.x}
      {$define StrictLong}
    {$else}
      {$define LoadArgs}
    {$endif}
  {$endif}

Gruß, Andreas

[bcvs]

Da fehlt ein {$ENDIF}. Jedes {$IFDEF} braucht ein {$ENDIF}

Delphi-Quellcode:

{$IFDEF CONDITION_0}
  A: string = //
  {$IFDEF IS_A} 'A' {$ELSE} //
  {$IFDEF IS_B} 'B' {$ELSE} //
  {$IFDEF IS_C} 'C' {$ELSE} //
   'ELSE' {$ENDIF}
   {$ENDIF}
   {$ENDIF}; //

{$ENDIF}

[Rollo62]

Oder so

Delphi-Quellcode:

{$IF IS_A}
{$ELSEIF IS_B}
{$ELSEIF IS_C}
{$IFEND}

http://docwiki.embarcadero.com/RADSt...LSEIF_(Delphi)

Es geht aber auch mit $ENDIF am Ende.
http://docwiki.embarcadero.com/RADSt...IFEND_(Delphi)

Was die Frage aufwirft, wozu der Quatsch mit IfEnd und EndIf, warum sollte der Kompiler nicht immer Beide nehmen können.

[himitsu]

Stimmt nicht ganz.
IFDEF und IF kann nicht "einfach" so getauscht werden.

IFDEF prüft ob der "Name" definiert ist,
aber IF prüft, ob die Condition True ergibt.

Aber {$IFDEF XYZ} = {$IF Defined(XYZ)} .
Für IF gibt nicht nur ein ELSE, sondern auch auch das ELSEIF
und man kann auch ganz nett mit OR, AND und Co. arbeiten.


Achtung:
IFDEF + ENDIF
IF + IFEND
aber, inzwischen kam wer auf die saublöde Idee ENDIF und IFEND gleich zu behandeln (vor paar Versionen) und am Ende nur noch IFEND zu erlauben,
aber gleichzeitig das nur im Compiler zu machen, anstatt es auch dem Error-Insight zu sagen.
Mit dem Ergebnis dass "Verwenden von Bedingungen für die Compiler-Version"
im http://docwiki.embarcadero.com/RADSt...ierung_(Delphi) komplett ad absurdum geführt wird.

[Rollo62]

Gut aufgepasst
Ich dachte das wäre klar, habs nur schnell hingeschrieben ...

Ich sehe bis jetzt keinen wirklichen Grund warum ifend und endif nicht das gleiche sein sollte.
Der Compiler könnte alle Fälle wunderbar separieren und auflösen.

Wahrscheinlich hat jemand gedacht man sollte das "neue" von dem "alten" unterscheiden können,
aus meiner Sicht würde es sowieso immer perfekt zusammenpassen.

Delphi-Quellcode:

// Start mit
{$IF}  // oder
{$IFDEF}  

//elseif kam mal dazu
{$ELSEIF}  

// final catchall für dem Rest
{$ELSE}  

//end, who cares
{$ENDIF}  
{$IFEND}

[himitsu]

Ja, das war auch Absicht, mit dem Unterscheiden.

Delphi hatte sich früher mal gerühmt so extrem abwertskompatibel zu sein, aber das war einmal,
und da war es gut, das man für Compiler bis Delphi 5 ein $IF im $IFDEF verstecken kann, weil er das noch nicht kennt.

Delphi-Quellcode:

{$IFDEF ConditionalExpressions}  // das springt bis zum nächsten $IFEND bzw. $ELSE
  {$IF xxxx}

  {$IFEND}  // heißt anders, damit $IFDEF es nicht als sein Ende erkennt
{$ELSE}
  ...
{$IFEND}

Delphi-Quellcode:

const abc = 13;

{$IF abc > 10}
oder
{$IF (abc > 10) and (abc < 15)}

Delphi-Quellcode:

{$IFNDEF VER150}  // hier wird es Spaß sich eine INC zu besorgen, um Versionen besser zu prüfen, was gern knallt, wenn man diese INC auf eine zu neue Delphi-Version los lässt
gegen
{$IF CompilerVersion < 15.0}

Oder ein lustiger Code für die Größenprüfung. (ja, zu Zeiten von 16 Bit gab es das $IF noch nicht)

Delphi-Quellcode:

{$IF SizeOf(Integer) = 2}
  {MESSAGE Hint '16 Bit'}
{$ELSEIF Declared(NativeInt) and (SizeOf(NativeInt) = 4)}
  {MESSAGE Hint '32 Bit'}
{$ELSEIF Declared(NativeInt) and (SizeOf(NativeInt) = 8)}
  {MESSAGE Hint '64 Bit'}
{$ELSEIF Declared(NativeInt)}
  {MESSAGE Hint 'gibt es endlich 128 Bit?'}
{$ELSE}
  {MESSAGE Hint '32 Bit, bevor der Mist mit dem "neuen" Integer erfunden wurde'}
{$IFEND}

[Rollo62]

Ja wenn DAS der Grund war.
Dann wäre ich gerne dafür mal alte Zöpfe abzuschneiden.

Es ist ja per Default auf beide Varianten eingestellt, meine ich.
Daher ist es auch OK, aber das man über solche Dinge überhaupt nachdenken muss ist schon Schade.

[himitsu]

Nachdenken muß man da nicht wirklich.
Nach all den Jahrzehnten weiß man es einfach und dann steht es auch immernoch so in der OH.

Es gehört einfach immer Zweiwas zusammen
IFDEF+ENDIF, IF+IFEND, BEGIN+END, IF+THEN, WHILE+DO, REPEAT+UNTIL, ...

Wenn man die Hilfe kennt und dann in Codes was Anderes sieht und auch das Error-Insight es eigentlich richtig als Falsch markiert (laut Definition), also das finde ich dann schon eher verstörend.

[Rollo62]

Vielleicht stehe ich ja gerade auf dem Schlauch, oder habe einen Bug im Error-Insight gefunden.
Jedenfalls sehe ich Error-Insight und Warnings immer bei IFEND,
egal wie die Compilerversion LEGACYIFEND eingestellt ist.
Ok, ich habe gerade nur bei iOS-64 gecheckt, vielleicht liegt es daran ?

Wie hast Du denn die Compileroption eingestellt, damit die Warnings und Error-Insight weg sind ?

Delphi-Quellcode:

{$IF DEFINED( DEBUG ) }
{$MESSAGE HINT 'IF-IFEND'}
{$IFEND }      // Error-insight (sollte doch nicht sein ?)

{$IF COMPILERVERSION > 13 }
{$MESSAGE HINT 'IF-GT-IFEND'}
{$IFEND }      // Error-insight (sollte doch nicht sein ?)

{$IFDEF DEBUG }
{$MESSAGE HINT 'IFDEF-ENDIF'}
{$IFEND }     // Error-insight

{$IF DEFINED( DEBUG ) }
{$MESSAGE HINT 'IF-ENDIF'}
{$ENDIF }     // Kein Error-insight (sollte doch hier kommen ?) Ein Error kommt aber bei LEGACYIFEND

{$IFDEF DEBUG }
{$MESSAGE HINT 'IFDEF-ENDIF'}
{$ENDIF }     // Kein Error-insight

Das war wahrscheinlich der Grund warum ich IFEND in der Regel ignoriert habe, ENDIF reicht mir aus und hat keine Fehler.