C++ Compiler Einstellung zu defines

[define (Gast)]

Hallo.

Const möchte ich aus bestimmten Gründen mal nicht verwenden. Ich habe 
aktuell viele mit #define definierte Werte, die sich gegeneinander auf 
Plausibelität prüfen. Bei einem Schreib- oder sonstigem Fehler greift 
der Compiler ins leere und gibt eine vorgesehene Meldung nicht aus, 
die eigentlich kommen müsste (z.B. Wert zu groß).

Gibt es eine Möglichkeit, dem Compiler zu sagen, dass er mit Fehler 
abbrechen soll, wenn er über eine Definition stolpert, die nicht 
definiert ist?

Beispiel

#define TEST 123
#if (TETS > 100)              // falsche Schreibweise
#error "Der Wert ist zu groß" // Diese Meldung bleibt natürlich aus
#endif                        // erzeugt aber auch keinen Fehler

void setup() {
}

void loop() {
}

Es betrifft natürlich nur "wegoptimierte" Definitionen, auf die nicht 
zugegriffen wird (zuküftige Ressourcen, die aber jetzt schon festgelegt 
worden sind). Ich verwende GCC.

[Vincent H. (vinci)]

So etwa?

#ifndef X
#error "bla"
#endif

[Niklas G. (erlkoenig)]

define schrieb:
> Const möchte ich aus bestimmten Gründen mal nicht verwenden.

Und die wären?

#ifndef TEST
#error "..."
#endif

oder

#if !defined(TEST) || TEST > 100
#error "..."
#endif

[Rufus Τ. F. (rufus)]

define schrieb:
> Gibt es eine Möglichkeit, dem Compiler zu sagen, dass er mit Fehler
> abbrechen soll, wenn er über eine Definition stolpert, die nicht
> definiert ist?

Nein. Abgesehen von der Spitzfindigkeit, daß der Compiler #defines 
sowieso nicht zu Gesicht bekommt (das macht der Präprozessor), würdest 
Du damit annähernd jeden existierenden Code unbrauchbar machen, denn das 
"Feature" undefinierter #defines wird intensiv genutzt -- dafür bietet 
der Präprozessor eigens #ifdef bzw. #if defined.

[Luther B. (luther-blissett)]

Hängt vom Compiler ab. Unter gcc und clang kannst du mit -Wundef 
kompilieren, dann gibt es eine Warnung oder -Werror=undef, dann bekommst 
du einen Fehler.

[Niklas G. (erlkoenig)]

Alternativ static_assert nehmen (portabel):

static_assert (TEST <= 100, "Test zu gross");

Das prüft wirklich der Compiler, und dazu muss der Ausdruck syntaktisch 
korrekt sein.

[Rufus Τ. F. (rufus)]

-Wundef

    Warn if an undefined identifier is evaluated in an #if directive. Such identifiers are replaced with zero.

Im gegebenen Fall würde das tatsächlich helfen.

[x^2 (Gast)]

define schrieb:
> Gibt es eine Möglichkeit, dem Compiler zu sagen, dass er mit Fehler
> abbrechen soll, wenn er über eine Definition stolpert, die nicht
> definiert ist?

Ja, das geht (aber wie bereits geschrieben, macht das der Präprozessor).

Typische Pattern:

#if 1/defined(TEST)
// do something if TEST is defined
#endif

#if 1/defined(TEST) && (TEST != 0)
// do something if TEST evaluates to TRUE
#else
// do something if TEST evaluates to FALSE
#endif

[Nein (Gast)]

x^2 schrieb:
> Typische Pattern:#if 1/defined(TEST)

Nein.
Absolut untypisch.

Den Not-Operator kennste?

[x^2 (Gast)]

Nein schrieb:
> x^2 schrieb:
>> Typische Pattern:#if 1/defined(TEST)
>
> Nein.
> Absolut untypisch.
>
> Den Not-Operator kennste?

Klar. Wieso?

[x^2 (Gast)]

Ok, Hauptsache mal zu Wort gemeldet.

Die Sache ist, dass der Präprozessor nicht definierte Symbole zu 0 
auswertet aber keinen Fehler erzeugt. Das ist historisch so. Das 
bedeutet bei

#if TEST != 0
// tue A
#else
// tue B
#endif

kann sich der Entwickler nicht sicher sein, ob B eincompiliert wird, 
weil TEST definiert und auf 0 gesetzt wurde, oder weil TEST gar nicht 
definiert ist. Das macht bei großen Projekten Probleme, wenn irgendwo 
ein #include vergessen wurde. Dann kann es passieren, dass verschiedene 
Modulen mit inkonsistenter Konfiguration compiliert werden. Will man 
nicht.

Wenn man statt dessen also einen Fehler möchte, kann man das so machen:

#if 1/defined(TEST) && (TEST != 0)
// tue A
#else
// tue B
#endif

Der Fehler entsteht, falls TEST nicht definiert ist, da der Präprozessor 
bei der Division durch 0 abbricht (1/0). Ist TEST definiert, steht dort 
(1/1) und somit

#if 1 && (TEST != 0)

Für das erfolgreiche compilieren muss TEST dann definiert sein und A 
wird eincompiliert falls TEST != 0 und andernfalls wird B eincompiliert 
falls TEST == 0. So wie man es erwarten würde - nur mit Fehler beim 
compilieren, falls TEST nicht definiert ist.

[Nein (Gast)]

x^2 schrieb:
> Der Fehler entsteht, falls TEST nicht definiert ist, da der Präprozessor
> bei der Division durch 0 abbricht (1/0). Ist TEST definiert, steht dort
> (1/1) und somit

Ja genau. Wie gesagt:
ifndef und !defined() kennste?
Was soll der Vorteil von der Division durch Null sein?

[x^2 (Gast)]

Ich finde es ist v.a. bei Verschachtelung übersichtlicher. Es läßt sich 
auch leicht automatisch prüfen (eine kleine regex reicht) ob es irgendwo 
fehlt. Im Vergleich:

#ifdef TEST
#if TEST != 0
// tue A
#else
// tue B
#endif
#else
#error "Missing TEST"
#endif

#if 1/defined(TEST) && (TEST != 0)
// tue A
#else
// tue B
#endif

Nachteil ist sicher, dass man sich erst mal daran gewöhnen muss, um 
nicht jedesmal bei der Zeile stutzig hängen zu bleiben.

[Nein (Gast)]

x^2 schrieb:
> #ifdef TEST
> #if TEST != 0
> // tue A
> #else
> // tue B
> #endif
> #else
> #error "Missing TEST"
> #endif

#ifndef TEST
#error "Missing TEST"
#elif TEST
// tue A
#else
// tue B
#endif

Vorteil: Man hat eine vernünftige Fehlermeldung, in der man auch noch 
erklären kann, was zu tun ist um das zu beheben, statt einer Division 
durch Null.

[define (Gast)]

OK, aus den Infos kann ich was machen. danke.

Die Makrobefehle kenne ich alle. Es sind ja nicht viele.

#ifdef ist keine Lösung. Will man jede Deklaration mit ifdef 
hinterprüfen, kommt man zu nichts anderem. Ab einer bestimmten 
Programmgröße jedenfalls. Zumal sich da auch wieder Fehler einschleichen 
können.

Die Plausichecks (natürlich vom Parser und nicht vom Compiler) sollen 
Konfigurationsfehler verhindern, und tun das auch sehr effizient. Mir 
ist es gestern aber passiert, dass ich eine Passage gelöscht habe, 
wodurch bestimmte Deklarationen nicht mehr gebraucht wurden. Diese 
blieben aber stehen, ich bin ja auch nur ein Mensch, und irgendwann habe 
ich mich gefragt, wieso da keine Meldung kommt, wenn auf verwaiste 
Ressourcen zugegriffen wird. Aber jetzt kenne ich ja den Grund. In 
Includfiles stehen jede Menge ungenutzte defines, das darf natürlich 
keinen Fehler geben. Wenn an auf diese defines zugreift, auf 
Präprozessor- oder Parserebene, sollte aber doch wenigstens eine Meldung 
kommen, statt den Wert 0 zugrunde zu legen. Das war mein Anliegen. Wenn 
das nicht geht, komme ich damit auch zurecht, ist halt anstrengend bei 
hunderten Zeilen Plausichecks. also danke nochmal.

[Hdudzevdjfd (Gast)]

Warum in C++ nicht constexpr und static_assert nehmen? Typischer und the 
C++ way. Defines braucht man in C++ ausschließlich für die include 
guards.

[Nein (Gast)]

$ cat t.c 
#if FOO
#endif
int main(void){}



$ gcc -Wundef -Werror=undef -o t t.c
t.c:1:5: error: "FOO" is not defined, evaluates to 0 [-Werror=undef]
 #if FOO
     ^~~
cc1: some warnings being treated as errors

[x^2 (Gast)]

Viele Wege führen offentlichtlich nach Rom.

Hdudzevdjfd schrieb:
> Warum in C++ nicht constexpr und static_assert nehmen? Typischer
> und the
> C++ way. Defines braucht man in C++ ausschließlich für die include
> guards.

Was ist mit bedingt compiliertem Code?

[Niklas Gürtler (Gast)]

x^2 schrieb:
> Was ist mit bedingt compiliertem Code?

Ist i.A. besser mit Template-Spezialisierung.