Delphi und FPC compiler problem

[Uwe Raabe]

Zitat von Rolf Frei:

Für mich schaut das nicht wirklich nach einem Bug aus, sondern ist vermutlich "As Designed".

Ich habe das mal in einen internen Channel gepostet. Mal abwarten wie die Reaktionen da ausfallen.

[KodeZwerg]

Zitat von Rolf Frei:

Das ist ein reines Compilier/Parser Problem und nicht ein Compilat Problem. Allfälliger Code innerhalb des IFDEF FPC wird ncht in das Programm compiliert. Das ist alles richtig und macht er auch so. Mit meinem obigen Lösungsansatz kannst du nach dem IFDEF FPC Müll reinschreiben und alles compiliert wie es sollte. Der Müll wird wie erwartet ignoriert.

Der Compiler wertet aber alle {$...} Zeilen aus, auch solche die er garnicht müsste. Da dort nun aber eine Referenz auf eine Konstante gemacht wird (FPC_VERSION >= 3) weiss der Delphi Compiler nicht was er damit anfangen soll, da er kein FPC_VERSION kennt. Ob da nun Defined oder Declared steht, hat für diesen Fehler keinen Einfluss, da dieser Teil eh nicht ins Compilat kommt.

@Uwe Raabe
Hab es eben mit D7 getestet und auch da kommt der Fehler aus gleichen Gründen. Wenn man da im IF einen Vergleich macht muss die entsprechende Konstante vorhanden sein, sonst knallt es.

Wie gesagt ist das ein reines Parser Problem und der Compiler macht da alles wie er muss, achtet also nicht auf das Zeugs innerhlab der IFDEF FPC beim compilieren. Für mich schaut das nicht wirklich nach einem Bug aus, sondern ist vermutlich "As Designed".

Ich vermute es ist so wie Du sagst, wenn es in mehr als zwei Zeilen kommt, ignoriert der Parser das vorige statement und sammelt daten die er vermutlich nicht brauchen wird aber denn nach Korrektheit auswertet.
Dank für diesen Beitrag!

[himitsu]

Zitat von Rolf Frei:

Für mich schaut das nicht wirklich nach einem Bug aus, sondern ist vermutlich "As Designed".

Ein Bug ist es ja dennoch.
Man macht ja extra ein IF/IFDEF drumrum, damit der Teil darin nicht beachtet wird, wenn man schon weiß, dass es das nicht gibt.

Wenn der Compiler/Parser nun dennoch da rein sieht, dann ist es sein Problem.

Wenn er es sich dennoch ansehen will/muß, und er von einem vorherrigen IF/IFDEF bereits weiß, dass der Teil garnicht benutzt wird, dann sollte er zumindestens die "Prüfbedingungung" bis zum abschließenden } ignorieren.



Ich vermute es geht darauf hinaus, seitdem Delphi IFEND und ENDIF als "gleich" betrachtet, bzw. krankhaft zwanghaft versucht ALLES auf Eines umzubiegen,
und seitdem auch die Dinge drinen parsen muß, um das "richtige" Ende zu finden.

Früher war es einfach, alles vom IFDEF bis zum "nächsten" ENDIF oder ELSE und IF/IFEND wurde ignoriert.
Ging ja ursprünglich auch nicht anders, weil damals die "alten" Compiler $IF noch garnicht kannten.

Delphi-Quellcode:

{$IFDEF ConditionalDefines}
  {$IF ...}

  {$IFEND}
{$ENDIF}

[Uwe Raabe]

Die erste Reaktion war diese Schreibweise, die ja auch schon von Frank in die Runde geworfen wurde:

Delphi-Quellcode:

{$IFDEF FPC}
  {$IF Declared(FPC_VERSION) and (FPC_VERSION >= 3)}
    {$DEFINE UNICODE}
  {$IFEND}
{$ENDIF FPC}

[Rolf Frei]

Zitat von himitsu:

Ich vermute es geht darauf hinaus, seitdem Delphi IFEND und ENDIF als "gleich" betrachtet, bzw. krankhaft zwanghaft versucht ALLES auf Eines umzubiegen,
und seitdem auch die Dinge drinen parsen muß, um das "richtige" Ende zu finden.

Das Problem besteht seit Anfang an, seit es die IF Anweisung gibt, die Defines und Konstanten auswerten kann. Wie ich bereits gschrieben habe, geht das auch in D7 nicht und verhält sich da genau geleich. Mit deiner erwähnten Änderung hat das wohl nichts zu tun.

@Uwe Raabe
Ok das finde ich dann sogar eine elegante Lösung für das Problem.

[KodeZwerg]

Zitat von Uwe Raabe:

Mach doch bitte einen BugReport dazu auf.

Conditional Compiling dont work as expect - erledigt, hoffe alles korrekt gemacht zu haben.

[himitsu]

Witzig, eigentlich nutzte ich gern AND und OR, weil dutzendfach verschachteltete IFDEFs nicht grade schön anzusehen sind und man oft genug garnicht mehr erkennt, was wann wo ist.

z.B. viele mehrfach verschachtelte Dinge aus den INCs von Indy, JEDI und Co., lassen sich oftmals durch wenige IF+ELSEIF ersetzen.


Und jetzt ist es plötzlich die Lösung für etwas, was mir so bisher noch garnicht aufgefallen war.

[KodeZwerg]

Zitat von himitsu:

Ich vermute es geht darauf hinaus, seitdem Delphi IFEND und ENDIF als "gleich" betrachtet, bzw. krankhaft zwanghaft versucht ALLES auf Eines umzubiegen,
und seitdem auch die Dinge drinen parsen muß, um das "richtige" Ende zu finden.

Früher war es einfach, alles vom IFDEF bis zum "nächsten" ENDIF oder ELSE und IF/IFEND wurde ignoriert.
Ging ja ursprünglich auch nicht anders, weil damals die "alten" Compiler $IF noch garnicht kannten.

Delphi-Quellcode:

{$IFDEF ConditionalDefines}
  {$IF ...}

  {$IFEND}
{$ENDIF}

{$LEGACYIFEND ON} ändert leider nichts.