C Präprozessor: Zeichenketten vergleichen oder anderes enum-ähnliches Konstrukt?

[Walter T. (nicolas)]

Hallo zusammen,

ich habe einen enum-ähnlichen Ausdruck, den ich schon im Präprozessor 
auswerten können muss. Also so:

     #define opt_trutenprugel  1
     #define opt_noelpenproettel  2
     #define opt_hoelterhofer  3
     #define opt_boelterkamp  4

(Das startet bei 1, damit nicht bei einem fehlenden #define der 
Vergleich 0 = 0 erfolgreich ist.)

Nun weiss ich allerdings durchaus den Komfort zu schätzen, wenn mich der 
Compiler bei switch-case-Umgebungen davor warnt, wenn ich einen Fall 
vergessen habe. Das geht bei den defines nicht.

Klar: Ich koennte jetzt zusätzlich ein enum definieren:

enum options_e
{
    opt_trutenprugel_ =    opt_trutenprugel,
    opt_noelpenproettel_ = opt_noelpenproettel,
    opt_hoelterhofer_ =    opt_hoelterhofer,
    opt_boelterkamp_ =     opt_boelterkamp,
}

oder geht es irgendwie besser?

[MaWin (Gast)]

Walter T. schrieb:
> oder geht es irgendwie besser?

Nicht wirklich.

[oerks (Gast)]

Es steht doch jedem selber frei, sich einen Praeprozessor zu
schreiben, der genau die Wunschfunktionen hat, die mann meint
unbedingt brauchen zu muessen.

Den haekelt man dann ins Makefile und alles wird gut.

Besitzer kommerzieller IDEs haben es da schwerer.
Die muessen einen Pre-Built-Step in ihre GUI klicken.
Und die Editoren und Codeparser werden bestimmt auch maulen.

[ich nehme den Preis nicht an (Gast)]

Walter T. schrieb:
> ch koennte jetzt zusätzlich ein enum definieren:enum options_e
> {
>     opt_trutenprugel_ =    opt_trutenprugel,

geht das überhaut?

[Rolf M. (rmagnus)]

ich nehme den Preis nicht an schrieb:
> Walter T. schrieb:
>> ch koennte jetzt zusätzlich ein enum definieren:enum options_e
>> {
>>     opt_trutenprugel_ =    opt_trutenprugel,
>
> geht das überhaut?

Warum sollte es nicht?

[A. S. (Gast)]

Wenn es nur 100 oder so sind, dann reicht es, die per Hand zu Pflegen. 
Mit entsprechendem Compile-Time-Asserts und wenn möglich, mit üblicher 
Schreibweise (#defines Groß)

Wenn es mehr sind, dann lass Dir die #defines aus dem enum mit einem 
Textfresser erzeugen. Das geht relativ einfach, wenn man sich an ein 
paar Regeln hält, z.B. alle enums im Klartext, nur einen pro Zeile, ... 
.

Die ganzen erzeugten Dinge kommen dann in eine generated.h (oder so) und 
werden im Make mit eingetragen.

[ich nehme den Preis nicht an (Gast)]

Rolf M. schrieb:
> Warum sollte es nicht?

weil alles vom Preprocessor ersetzt wird.

[ich nehme den Preis nicht an (Gast)]

Walter T. schrieb:
> opt_trutenprugel_

Ach, da ist ein Untersrich am Ende!

Meine Güte, das sieht man doch nicht ;-)

[Walter T. (nicolas)]

A. S. schrieb:
> Wenn es nur 100 oder so sind, dann reicht es, die per Hand zu Pflegen.

So viele sind es zum Glück nicht. Der Pflegeaufwand hält sich in 
Grenzen. Was mich an der Lösung stört, ist dass die Schreibweise unter 
Umständen Verwirrung stiften kann. (MAKROS sehen wie enums_aus, enums_ 
sehen so aus, als wären sie etwas Besonderes, obwohl sie das "normalere" 
sind.)
Ein Tippfehler (vergessener Unterstrich am Ende) wird folgenlos bleiben.
Ich will nur sicherstellen, dass ich mich nicht an etwas Merkwürdiges 
gewöhne.

[Klaus H. (klummel69)]

Walter T. schrieb:
> Nun weiss ich allerdings durchaus den Komfort zu schätzen, wenn mich der
> Compiler bei switch-case-Umgebungen davor warnt, wenn ich einen Fall
> vergessen habe. Das geht bei den defines nicht.

Ich verstehe deine Frage nicht. Sowas geht doch:

#define opt_trutenprugel  1
#define opt_noelpenproettel  2
#define opt_hoelterhofer  3
#define opt_boelterkamp  4

#define option 1

#if (option == opt_trutenprugel)
    #pragma message ("Do case 1")
    //...
#elif (option == opt_noelpenproettel)
    #pragma message ("Do case 2")
    //...
#elif (option == opt_hoelterhofer)
    #pragma message ("Do case 3")
    //...
#elif (option == opt_boelterkamp)
    #pragma message ("Do case 4")
    //...
#else
    #error Invalid option!
#endif

Damit (else zweig) kann man prüfen, ob eine Option falsch gesetzt wurde.
Meinst Du etwas anderes?

[Walter T. (nicolas)]

Klaus H. schrieb:
> Damit (else zweig) kann man prüfen, ob eine Option falsch gesetzt wurde.
> Meinst Du etwas anderes?

Viele Sachen muss ich nicht im Präprozessor prüfen, sondern es reicht 
ein normales switch-case

    enum options_e a = 1;
    switch( a )
    {
        case opt_trutenprugel_: /* Fallthru */
        case opt_noelpenproettel_: /* Fallthru */
        case opt_hoelterhofer_:
            break;
    }

Und der Compiler merkt sofort:

src_application\debugme.c|75|warning: enumeration value 'opt_boelterkamp_' not handled in switch [-Wswitch]|

Das ist schön. Es vereinfacht ungemein Implementierungen nach dem 
"YAGNI"-Prinzip. (Wenn man eine neue Variante benötigt, neues 
Enum-Element, und an den Stellen ergänzen, wo der Compiler dessen Fehlen 
bemängelt.)

[Klaus H. (klummel69)]

Ahhh, jetzt hab ich's kapiert. Merci!

Die -Wswitch ist beim direkten Tippen / Compilieren nicht schlecht.
Aber ich versuche meine Funktionalitäten per Tests zu prüfen.
Spätestens dann fällt einem eine nicht vorhandene Case auf.

Ich habe mal ein Tool in Python gemacht,
dass verschiedene andere Szenarien geprüft hat.
Aber hier lohnt sich vermutlich der Aufwand nicht,
bzw. man sollte die Zeit ins Testen investieren.

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

Walter T. schrieb:
> ich habe einen enum-ähnlichen Ausdruck, den ich schon im Präprozessor
> auswerten können muss.

Wobei sich mir die Frage stellt, warum.

Früher ging das nur so, aber mittlerweile sind die Compiler doch 
problemlos in der Lage, zur Compilezeit konstante Ausdrücke auch selbst 
zu berechnen. Wenn diese dann in Bedingungen benutzt werden, die 
konstant "false" sind, wird der entsprechende Code nicht generiert – 
nicht anders als bei einem #if 0 im Präprozessor.

[BeBe (Gast)]

Jörg W. schrieb:
> Früher ging das nur so, aber mittlerweile sind die Compiler doch
> problemlos in der Lage, zur Compilezeit konstante Ausdrücke auch selbst
> zu berechnen.

Jepp. Aber solche Fälle werden selten per switch case realisiert.
Oft hab ich an verschiedenen Stellen if()...else if....

Da hilft die -Wswitch Warnung nicht....

[Walter T. (nicolas)]

Jörg W. schrieb:
> Wobei sich mir die Frage stellt, warum.

Wenn ich die Frage beantworte, wird man mir wieder Obskurität vorwerfen.

Ich habe in meinem Projekt eine Konfigurationsdatei, in der alle
Hardware-Einstellungen stehen. Damit lässt sich halbwegs einfach
Übersicht halten, welche Hardware-Ressourcen wofür belegt sind. Für eine
Timer-ISR sieht das so aus:

/* config_nucleo.h */
#define FAST_LOOP_ISR_TIMx    timer_isr_STM32F4XX_TIM6
#define FAST_LOOP_IRQ_HANDLER TIM6_DAC_IRQ_Handler

#define SLOW_LOOP_ISR_TIMx    timer_isr_STM32F4XX_TIM7
#define SLOW_LOOP_IRQ_HANDLER TIM7_IRQHandler

#define BUZZER_PWM            buzzer_STM32F4XX_TIM4_PB7

#define ENCODER_HARD_AUX0     encoder_STM32F4XX_TIM5_PA0_PA1
#define ENCODER_HARD_AUX1     encoder_STM32F4XX_TIM2_PB8_PB9
#define ENCODER_HARD_AUX2     encoder_STM32F4XX_TIM3_PB4_PB5

/* Grafik-LCD: SPI-Port (Hard-SPI mit DMA) */
//#define SPI_HARD_DMA spi_hard_none
#define SPI_HARD_DMA spi_hard_STM32F4XX_SPI1_PA5_PA6_PA7
//#define SPI_HARD_DMA spi_hard_STM32F4XX_SPI2_PB13_PB14_PB15
//#define SPI_HARD_DMA spi_hard_STM32F4XX_SPI3_PC10_PC11_PC12

/* ... */

Wie man sieht, geht es bei den Timern schon etwas eng zu, dass man 
Übersicht gut gebrauchen kann. Und Ressourcen (z.B. Pins) mit Strg-F 
suchen zu können finde ich auch nützlich.


Die Werte sind als enum in einem anderen Header hinterlegt:

/* anderer_header.h */
enum timer_isr_e
{
    timer_isr_none,
    timer_isr_STM32F4XX_TIM6,
    timer_isr_STM32F4XX_TIM7,
    timer_isr_systick,
};

/** Hilfsfunktion: Timer auswaehlen */
static_inline TIM_TypeDef* timer_isr_which(enum timer_isr_e timer)
{
    switch( timer )
    {
        case timer_isr_none:
            return NULL;
        case timer_isr_STM32F4XX_TIM6:
            return TIM6;
        case timer_isr_STM32F4XX_TIM7:
            return TIM7;
        case timer_isr_systick:
            return NULL;
        default:
            return NULL;
    }
}

/** Timer-ISR-Startup; funktioniert auch fuer SysTick
 * @param[in] timer: enum Timer */
static_inline void isr_function_startup(enum timer_isr_e timer)
{
    switch( timer )
    {
        case timer_isr_none:
            assert( false );
            break;

        case timer_isr_STM32F4XX_TIM6: /* fallthru */
        case timer_isr_STM32F4XX_TIM7:
            {
                TIM_TypeDef* TIMx = timer_isr_which(timer);
                TIM_ClearITPendingBit(TIMx, TIM_IT_Update);
            }
            break;

        case timer_isr_systick:
            break;
    }
}

/** Timer-ISR-Ende
 * @param[in] timer: enum Timer */
static_inline void isr_function_closing(enum timer_isr_e timer)
{
    /* kein implementierter Timer benoetigt aufraeumen am Ende */
    (void) timerIsr;
}

Initialisierung usw. lässt sich in normalen C-Funktionen dann recht
komfortabel mit switch/case auswählen, und der Compiler warnt
netterweise, damit auch nichts vergessen wird.

Die eigentliche ISR sieht dann so aus:

/* andere .c */
/** Timer-Funktion */
void FAST_LOOP_IRQ_HANDLER(void)
{
    /* z.B. ISR-Status-Bits behandeln */
    isr_function_startup(FAST_LOOP_ISR_TIMx);
    do_some_stuff();
    isr_function_closing(FAST_LOOP_ISR_TIMx);
}

Man beachte, dass das zweite #define in der Config-Datei nur deshalb
benötigt wird, weil ich mit Präprozessor-Direktiven nicht auch
enum-Werte vergleichen kann. Sei's drum. Ansonsten geht es gut und
meiner Meinung nach komfortabler, als im ISR Vector Table
herumzuschreiben.

Jetzt habe ich mir den Spaß gemacht, und eine der ISRs in Assembler
nachprogrammiert:

/* andere.S */
.align 4
.text
.type TIM6_DAC_IRQHandler, %function
.global TIM6_DAC_IRQHandler
TIM6_DAC_IRQHandler:
    @ IT pending Bit loeschen TIMx->SR = (uint16_t)~TIM_IT;
    ldr r0, =TIM6_BASE
    ldr r1, =~TIM_IT_Update
    str r1, [r0, #TIMx_SR]

    @ Nutzlast
    do s0, m3
    stu #FF
    bx lr
    .ltorg

Der globale Funktionsname lässt sich noch problemlos über den
C-Präprozessor austauschen. Mit der Präambel sieht es allerdings anders
aus. Hier fällt mir kein außer dem im Eröffnungsbeitrag genannten 
Mechanismus ein, wie mich
Compiler/Assembler zur Compilezeit wenigstens warnen könnte, dass die
implementierte ISR nicht mehr funktionieren wird.

[A. S. (Gast)]

Walter T. schrieb:
> Compiler/Assembler zur Compilezeit wenigstens warnen könnte, dass die
> implementierte ISR nicht mehr funktionieren wird.

Du kannst einen "default" anlegen und dort ein Konstrukt unterbringen, 
der bei Deinen Warnungen anschlägt, wenn der Code durchlaufen wird.

Ich kenne Deine Warnungen nicht. Möglich wäre sowas wie set twice before 
used. Oder etwas mit einer uninitialisierten Variable. Wichtig ist nur, 
dass der Compiler bzw. das Analysetool nur dann anspricht, wenn der Code 
wirklich durchlaufen wird.

Sobald Du ein Konstrukt gefunden hast, wird es aufgehübscht, mit schönen 
Makros und Namen versehen und ist dann so selbstverständlich wie ein 
Compile-Time-Assert.

[Klaus H. (klummel69)]

Deinen Aufbau von timer_isr_which() würde ich ändern.

Wenn ein ungültiger Wert übergeben wird, dann läuft dein Programm 
weiter. Einen NULL Pointer zurückzugeben halte ich für fehleranfällig.

Mit static Assertions kommst du nicht weit, da die Funktion so definiert 
ja auch mit Werten umgehen muss, die erst zur Laufzeit bekannt sind.
Ich würde die case Pfade die "eigentlich" nicht möglich sind, auch mit 
Assertions abfangen, vor allem den default Zweig.

In isr_function_startup() hast du das ja zumindest einmal so gemacht.

Ich nutze BTW in meinen embedded Programmen eine Runtime Assertion, die 
auch im Release drin bleibt. Man glaubt gar nicht wie oft ein Szenario 
eintritt, das "sowieso niemals" auftreten kann.

[Klaus H. (klummel69)]

Walter T. schrieb:
> Ich habe in meinem Projekt eine Konfigurationsdatei, in der alle
> Hardware-Einstellungen stehen.

Die Vorgehensweise mit der Konfigurationsdatei ist OK, mach ich auch 
gerne so. Allerdings kann es Konflikte geben, wenn eine Ressouce 
mehrfach eingesetzt wird. Nicht immer entsteht dadurch ein 
Compilerfehler.
Wie fängst Du Kollisionen ab?

[Rolf M. (rmagnus)]

Klaus H. schrieb:
> Ich nutze BTW in meinen embedded Programmen eine Runtime Assertion, die
> auch im Release drin bleibt. Man glaubt gar nicht wie oft ein Szenario
> eintritt, das "sowieso niemals" auftreten kann.

Aber was macht deine Assertion da? Auf einem µC kann man ja in der Regel 
nicht einfach mal eine Fehlermeldung anzeigen und das Programm beenden.
Man braucht dann eher extra Code, der den Fall irgendwie behandelt und 
das Programm wieder in einen sauberen Zustand oder zumindest eine 
Rückfallebene überführt.

[Klaus H. (klummel69)]

Rolf M. schrieb:
> Aber was macht deine Assertion da? Auf einem µC kann man ja in der Regel
> nicht einfach mal eine Fehlermeldung anzeigen und das Programm beenden.

Das kommt auf das Embedded System an.
Wenn das System „Stehen bleiben kann“ springe ich in eine Endlosschleife 
und gebe den Fehler aus. Entweder über das Display oder über eine 
serielle Schnittstelle - schlimmstenfalls über einen Standard Pin per 
Software emulierter serieller Schnittstelle oder als LED Morsecode.
In Systemen, die weiterlaufen sollen, wird nach x Sekunden Fehleranzeige 
ein Reset generiert.

Die Frage ist doch eher was machen embedded Programme, die keine fatalen 
Fehler per Assertions abfangen?

[Walter T. (nicolas)]

Klaus H. schrieb:
> Wie fängst Du Kollisionen ab?

Gar nicht. Es ist nur eine Merkhilfe.

Rolf M. schrieb:
> Aber was macht deine Assertion da?

Bei mir springt sie in den Hardfault-Handler. Wenn das Display schon 
initialisiert ist, steht dann eine Fehlermeldung da. Wenn nicht, wird 
wenigstens "........" gemorst.

Wenn eine Assertion fehlschlägt, ist sowieso spätestens der Punkt 
erreicht, mit dem Debugger nachzugucken.

Klaus H. schrieb:
> Wenn ein ungültiger Wert übergeben wird, dann läuft dein Programm
> weiter. Einen NULL Pointer zurückzugeben halte ich für fehleranfällig.

Alle nicht-Header-Funktionen prüfen grundsätzlich auf Nullzeiger - 
insbesondere alle init()-Funktionen. Das sollte schnell auffallen. Ich 
versuche Assertions in static-inline-Funktionen weitestgehend zu 
vermeiden, weil die Zuordnung zum Quelltext sehr oft nicht einfach ist.

[Klaus H. (klummel69)]

Walter T. schrieb:
> Alle nicht-Header-Funktionen prüfen grundsätzlich auf Nullzeiger -
> insbesondere alle init()-Funktionen. Das sollte schnell auffallen.

Defensive Programmierung 👍👍👍

Damit erschlägst Du doch einen Großteil deiner obigen Anfrage.
Präprozessorkonstrukte, die "zukünftige" neue Konfigurationen aufdecken 
können würde ich so eher nicht umsetzen.

[Rolf M. (rmagnus)]

Klaus H. schrieb:
> Die Frage ist doch eher was machen embedded Programme, die keine fatalen
> Fehler per Assertions abfangen?

Ich sage ja nicht, dass man ihn nicht abfangen soll, sondern eher, dass 
assertions gerade im Embedded-Bereich oft schwierig sind.
Deshalb ja auch:

Rolf M. schrieb:
> Man braucht dann eher extra Code, der den Fall irgendwie behandelt und
> das Programm wieder in einen sauberen Zustand oder zumindest eine
> Rückfallebene überführt.

[Walter T. (nicolas)]

Rolf M. schrieb:
> Ich sage ja nicht, dass man ihn nicht abfangen soll, sondern eher, dass
> assertions gerade im Embedded-Bereich oft schwierig sind.
> Deshalb ja auch:
>
> Rolf M. schrieb:
>> Man braucht dann eher extra Code, der den Fall irgendwie behandelt und
>> das Programm wieder in einen sauberen Zustand oder zumindest eine
>> Rückfallebene überführt.

Nach meinem Kenntnisstand kommt nach einer fehlgeschlagenen Assertion 
keine "graceful Degradation" mehr (im Gegensatz zu "error()" oder 
try-catch). Nach einer fehlgeschlagenen Assertion ist das System tot. 
Deswegen sind sie auch (im Gegensatz zu den anderen beiden) nur im 
Debug-Code aktiv.

Aber das entfernt sich so langsam vom eigentlichen Thema. Es ging ja 
eigentlich um präprozessortaugliche Enum-ähnliche Konstrukte. Wobei das 
andere Thema sicherlich interessant genug ist, einen eigenen Thread zu 
rechtfertigen.

[Klaus H. (klummel69)]

Eine Idee zu deinem ursprünglichen Problem hätte ich noch:

Wenn die switch Strukturen immer mit Konstanten gefüttert werden,
so dass ungenutzter Code raus optimiert werden kann,
dann könntest Du "Linker Assertions" nutzen.

Beispiel:

extern void function_does_not_exist(void);
#define CODE_SHOULD_NOT_BE_USED_ASSERT() function_does_not_exist()

static_inline TIM_TypeDef* timer_isr_which(enum timer_isr_e timer)
{
    switch( timer )
    {
        case timer_isr_none:
            return NULL;
        case timer_isr_STM32F4XX_TIM6:
            return TIM6;
        case timer_isr_STM32F4XX_TIM7:
            return TIM7;
        case timer_isr_systick:
            return NULL;
        default:
            CODE_SHOULD_NOT_BE_USED_ASSERT();
            return NULL;
    }
}

Geht allerdings nur, wenn die Toolchain optimieren darf (z.B. gcc -O1).
Dann erkennst Du aber immerhin beim Linken, wenn neue case Pfade fehlen.
Das müsste dann auch bei if() else if() else ... funktionieren.

[Vincent H. (vinci)]

Mit Boost PP könnte man da vermutlich irgendwas unleserliches 
zusammenhacken... davon würde ich aber abraten. Sinnvoller wäre es 
vermutlich eine Programmiersprache zu verwenden die die gewünschten 
Konstrukte unterstützt.