#define auf enum

[Walter T. (nicolas)]

Hallo zusammen,

ich bin gestern auf ein Problem gestoßen, dessen ich mir vorher nicht 
bewusst war. Das Programm sah sinngemäß so aus:

enum choice_e
{
    choice_a,
    choice_b,
};

#define MYCHOICE choice_b


/* Funktion zum Testen von Sachen. */
char runToShow(void)
{
    volatile char a;

    #if( MYCHOICE == choice_a )
        a = 'a';

    #elif( MYCHOICE == choice_b )
        a = 'b';

    #else
        #error "Invalid choice"

    #endif

    volatile char b = 'c';

    return a;
}

Die beiden volatile-Variablen haben nur den Zweck, einen Breakpoint im 
Debugger setzen zu können.

Ich nehme mal an, dass hier jeder weiss, welchen Wert die Funktion 
zurückgibt. Aber warum gibt sie diesen Wert zurück?

[Martin (Gast)]

Walter T. schrieb:

> Ich nehme mal an, dass hier jeder weiss, welchen Wert die Funktion
> zurückgibt. Aber warum?

Weil sie die Sprache C beherrschen.

[Rolf M. (rmagnus)]

Walter T. schrieb:
> Aber warum?

Weil der Präprozessor nur Präprozessor-Direktiven auswertet. Enums 
kommen erst später, im eigentlichen Compiler, dran.

[Walter T. (nicolas)]

Ich habe die Frage angepasst, weil ich vergessen habe, dass hier mehr 
Compiler als Menschen unterwegs sind.

Dass Enums erst später ausgewertet werden, ist mir auch bewusst 
geworden. Aber warum ist der Wert von "choice_a" für den Präprozessor 
überhaupt definiert und er wandert nicht in den Fehlerzweig?

[Rolf M. (rmagnus)]

Der Präprozessor macht nach der Makro-Ersetzung bei == einen numerischen 
Vergleich der Werte auf beiden Seiten. Zuerst wird MYCHOICE durch 
choice_b ersetzt. Alle Identifier, die keine Makro-Namen sind, 
evaluieren zu 0. Da es kein Makro namens choice_b gibt, wird da also 0 
draus. Ein Makro namens choice_a gibt es ebenfalls nicht, also kommt da 
auch 0 raus. Damit sind beide Seiten gleich. Das würde übrigens auch auf 
das #elif zutreffen, aber das kommt ja gar nicht erst dran.

Walter T. schrieb:
> Ich habe die Frage angepasst, weil ich vergessen habe, dass hier mehr
> Compiler als Menschen unterwegs sind.

Sorry, ich hab meinen Text jetzt aus Sicht des Compilers (genau genommen 
des Präprozessors) geschrieben. Ich hoffe, das ist trotzdem ok…

[Walter T. (nicolas)]

Hallo Rolf,
bitte entschuldige die missverständliche Formulierung. Auf Deine Antwort 
war die Bemerkung nicht bezogen, sondern auf die davor.

Danke, die Erklärung klingt so, dass die Chancen sehr gut sind, dass ich 
sie mir merken kann.

[Jörg W. (dl8dtl) (Moderator)]

Walter T. schrieb:
> Aber warum ist der Wert von "choice_a" für den Präprozessor überhaupt
> definiert

Kannst du übrigens auch warnen lassen (-Wundef) und per -Werror als 
Fehler behandeln lassen.

[A. S. (Gast)]

Walter T. schrieb:
> Danke, die Erklärung klingt so, dass die Chancen sehr gut sind, dass ich
> sie mir merken kann.

Oder Warnungen einschalten, dann sagt er, dass beide nicht definiert 
sind.

Das wäre aber so eine Warnung, die ich je nach Architektur der SW auch 
ausschalte.

[Walter T. (nicolas)]

Danke für die Tipps mit der Warning. Mal wieder etwas, was in -Wpedantic 
nicht drin ist.

[BeBe (Gast)]

Die meisten #if Konstrukte können inzwischen mit normalen if gelöst 
werden. Die Compiler sind inzwischen sehr gut. Ich nutze #if Konstrukte 
eigentlich nur für Plattformschalter und dann meistens auch nur 
außerhalb von Funktionen.
Falls man sich auf den -Wpedantic Schalter nicht verlassen will (ich 
kenne meine Kollegen) kann man wichtige Proprozessor Werte auch direkt 
prüfen.

#if !defined(M51TBL) || !defined(SERIAL) || !defined(MODEL)
#error "Important compiler switches are undefined! "
#endif

[A. S. (Gast)]

BeBe schrieb:
> #if !defined(M51TBL) || !defined(SERIAL) || !defined(MODEL)
> #error "Important compiler switches are undefined! "
> #endif

Geht das auch rekursiv? In diesem Fall ist es ja so, dass MYCHOICE 
definiert war.

[Stefan F. (Gast)]

A. S. schrieb:
>> #if !defined(M51TBL) || !defined(SERIAL) || !defined(MODEL)
>> #error "Important compiler switches are undefined! "
>> #endif

> Geht das auch rekursiv? In diesem Fall ist es ja so, dass MYCHOICE
> definiert war.

Ich kann die Frage nicht beantworten, aber ich kann von obigem Konstrukt 
nur abraten. Denn die Fehlermeldung sagt nicht, welcher "switch" fehlt. 
Lieber ein bisschen weniger faul sein, und drei individuelle 
Fehlermeldungen programmieren. Man schießt sich sonst nur unnötig ins 
eigene Knie.

[Frank M. (ukw) (Moderator)]

Preprocessor- und enum-Konstanten zu mischen ist keine gute Idee.

Wenn man das at-compile-time abfangen will, wäre dies eine Lösung:

#define choice_a    0
#define choice_b    1

Dann kann der Rest des Codes so bleiben.

Okay, man sollte vielleicht choice_a und choice_b noch groß schreiben, 
um auszudrücken, dass es sich um Preprocessor-Konstanten handelt.

[BeBe (Gast)]

Stefan ⛄ F. schrieb:
> Ich kann die Frage nicht beantworten, aber ich kann von obigem Konstrukt
> nur abraten. Denn die Fehlermeldung sagt nicht, welcher "switch" fehlt.
> Lieber ein bisschen weniger faul sein, und drei individuelle
> Fehlermeldungen programmieren. Man schießt sich sonst nur unnötig ins
> eigene Knie.

Du hast natürlich Recht, Einzelfehlermeldungen sind DAU Idiotensicher.
Zusammengefasst sehe ich aber im Beispiel dass einer von 3 nicht da ist.
Das ist dann nur noch Programmieranfänger-Unsicher.

Ins Knie schiesse ich mir damit nicht, das ist in einer normalen IDE 
schnell entdeckt.

[A. S. (Gast)]

Frank M. schrieb:
> #define choice_a    0

Wobei wir generell 0 als Auswahlwert vermeiden. Eben weil jede falsche 
Schreibweise zu 0 führt. 0 ist quasi nur literal als ausschalten 
erlaubt, bzw. hier "No choice".

[Stefan F. (Gast)]

BeBe schrieb:
> Ins Knie schiesse ich mir damit nicht, das ist in einer normalen IDE
> schnell entdeckt.

Das denke ich auch oft. Und 5 Jahre später sitze ich dann davor und 
frage mich "Welcher Vollidiot hat das gemacht?". Ich kann mir dann nicht 
einmal vorstellen, dass ich das selbst war.

[A. S. (Gast)]

Stefan ⛄ F. schrieb:
> Ich kann die Frage nicht beantworten

War auch nur rhetorisch.

Wie Frank schon schrieb, gehören enums nicht in #if.

Und besser auf 0 abfragen, dann ist !defined mit drin. 0 dann natürlich 
als Merkmal reservieren.


#if !M51TBL || !SERIAL || !MODEL

[BeBe (Gast)]

A. S. schrieb:
> Geht das auch rekursiv? In diesem Fall ist es ja so, dass MYCHOICE definiert 
war.
Regel: Du solltest Präprozessor  ifs nur für Compilerschalter nutzen und 
nicht mit enums vermischen.
Präprozessor  Anwendung nur für verschiedene Plattformen/ Ausprägungen:

#if defined(EMBEDDED_OS)…

Wenn du außerhalb von Funktionen Bedingungen brauchst, geht halt nur #if 
und dann machen enums keinen Sinn)
In deinem Beispiel brauchst Du aber kein Präprozessor if. Das erledigt 
das normale if auch.
Ich hab mal Deinen Code angepasst.

#include<stdio.h>
#include <assert.h>

enum choice_e {choice_a,choice_b};

enum config_e {my_choise = choice_b};
//enum config_e {my_choise = 68768};

// Check: statt "#if defined " korrekte Einstellung mit Static_assert prüfen (ab C11) 
_Static_assert (my_choise==choice_a || my_choise==choice_b , "Falsche Konfiguration");



char runToShow(void)
{
    volatile char a;
    if( my_choise == choice_a )
    {
        a = 'a';
    }
    else if ( my_choise == choice_b )
    {
        a = 'b';
    }
    else
    {
        // Fehlermeldung provozieren
        assert(0); // 1. runtime assertion, oder
        error_else_path_not_allowed(); // 2. Linkerfehler durch unbekannte Funktion
    }
    return a;
}

int main()
{
    char ret;
    ret = runToShow();
    printf("%c", ret);
}

So meckert der Compiler wenn my_choise ,choice_a… nicht definiert sind. 
(expected expression before '==' token)
Wenn man eine Felermeldung im else Zweig braucht, gibt es zwei 
Möglichkeiten in C:
1.  Runtime assert erzeugen
2.  oder einen Linkerfehler provozieren.

(In C++ könnte man ggf im else Zweig ggf per templates einen 
Compilerfehler erzeugen.)

Nicht perfekt und holprig. Ich will Präprozessor ifs nicht verteufeln, 
man braucht sie immer mal wieder, aber man sollte die Alternativen 
kennen. (Ich baue meine Sachen inzwischen in C++, dort ist der Umgang 
mit Konstanten deutlich besser).

[Stefan F. (Gast)]

Das stimmt, manchen Leuten ist nicht klar, dass der Compiler toten Code 
sowieso weg optimiert. Es geht sogar noch weiter:

#define debug_enabled false

void debug_print(char* message)
{
    if (debug_enabled)
    { 
       ... // Meldung irgendwie ausgeben
    }
}

int main()
{
    debug_print("main gestartet");
    ....
    debug_print("main beendet");
}

Hier wird nicht nur die Ausgabe weg gelassen, sondern die ganze Funktion 
debug_print() und auch die Strings werden weg optimiert.

Dieser Hokuspokus mit komplexen #ifdef Makros ist nur selten nötig. 
Stattdessen riskiert man, den Quelltext schlecht lesbar zu machen und 
die Makros falsch zu benutzen.

[Jörg W. (dl8dtl) (Moderator)]

Stefan ⛄ F. schrieb:
> Hier wird nicht nur die Ausgabe weg gelassen, sondern die ganze Funktion
> debug_print() und auch die Strings werden weg optimiert.

Bei Verteilung auf mehrere Quelldateien allerdings nur, wenn man -flto 
benutzt. Der Compiler weiß ja ansonsten in Datei A nicht, dass die 
aufgerufene Funktion, deren Implementierung sich in Datei B befindet, 
eigentlich gar nichts tut.

[Stefan F. (Gast)]

Jörg W. schrieb:
> Bei Verteilung auf mehrere Quelldateien allerdings nur, wenn man -flto
> benutzt.

Ja guter Hinweis

[BeBe (Gast)]

Stefan ⛄ F. schrieb:
> Hier wird nicht nur die Ausgabe weg gelassen, sondern die ganze Funktion
> debug_print() und auch die Strings werden weg optimiert.

Volle Zustimmung. Viele glauben, dass der Compiler im letzten 
Jahrtausend stehen blieb. ("C11 - was ist das?")

Wobei Lustigerweise Debug Funktionen wie debug_print() die einzigen 
Funktionen sind, die ich per Präprozessor wrappe.
Aber eher wegen _LINE_ Macro als wegen Optimierungen... ;-)

[Mark B. (markbrandis)]

Walter T. schrieb:
> Ich nehme mal an, dass hier jeder weiss, welchen Wert die Funktion
> zurückgibt. Aber warum gibt sie diesen Wert zurück?

Die viel interessante Frage ist doch:
Warum um alles in der Welt sollte man solchen Code schreiben wollen?

[Walter T. (nicolas)]

My goals are beyond your understanding.

[Rolf M. (rmagnus)]

Walter T. schrieb:
> My goals are beyond your understanding.

Wenn andere nicht verstehen, was du tust, gibt es dafür zwei mögliche 
Ursachen ;-)

[Walter T. (nicolas)]

Rolf M. schrieb:
> Wenn andere nicht verstehen, was du tust, gibt es dafür zwei mögliche
> Ursachen ;-)

Mir fallen noch mehr ein. In diesem Fall ist sie banal: Die Frage ist so 
formuliert, dass der Eindruck entsteht, dass keine echte Antwort 
erwartet wird.

Falls es trotzdem jemanden interessieren sollte: 
Beitrag "STM32F446RE - Timer 4 PB7 geht nicht"