Verschiedene typedef enum als unterschiedliche Datentypen behandeln?

[Thorsten (Gast)]

Hallo, liebe C-Experten,

ich habe momentan in einem uC-Programm diverse Funktionen, die jeweils 
verschiedene Enums als Parameter bekommen und möchte mehr 
Datentypsicherheit erreichen, als mit dem enum-Ansatz möglich zu sein 
scheint.

Der Beispielcode (für PC, aber das Problem ist das gleiche) im Anhang 
macht das Problem hoffentlich deutlicher als meine Beschreibung es kann.

Kann man irgendwie mit einem anderen Ansatz erreichen, dass die Fehler 
in den Zeilen mit /* WRONG */ schon beim Kompilieren auffallen?

viele Grüße,
Thorsten

[Klaus W. (mfgkw)]

ja, indem man C++ nimmt

[Karl H. (kbuchegg)]

Thorsten schrieb:

> Kann man irgendwie mit einem anderen Ansatz erreichen, dass die Fehler
> in den Zeilen mit /* WRONG */ schon beim Kompilieren auffallen?

Es gäbe schon eine Möglichkeit, aber die verschleiert mehr als das sie 
nützt.
Man könnte structs misbrauchen

typedef struct 
{
  uint8_t value;
} color;

color white = { 0 };
color red   = { 1 };
color blue  = { 2 };

void foo( color col )
{
  if( col.value == white.value )
    ...
}

schön ist es immer noch nicht, aber zumindest kriegst du dann eine 
andere struct nicht so leicht an foo durch.

Finde dich damit ab, dass enums in C keine wirkliche Lösung sind.

[Klaus W. (mfgkw)]

Hinweis (nicht neu, gibt es schon an anderer Stelle, aber es passt
hier):

Man kann (zumindest falls es um AVR geht) seinen Quelltext als .cpp
statt .c schreiben und entsprechend mit avr-g++ statt avr-gcc
kompilieren, wobei letzteres nicht mal nötig wäre.

Der inhaltlich gleiche Quelltext wird dann halt als C++ kompiliert.
Auch wenn man C++ nachsagt, mehr Resourcen zu benötigen, die man auf
einem MC nicht hat, handelt man sich dadurch keine Nachteile ein
hinsichtlich Codegröße, Laufzeiteffizienz etc. und kann trotzdem
etliche Vorzüge von C++ genießen, wie hier die strengere
Typkontrolle.
Erst wenn wenn man neumodischen Kram wie Klassen mit virtuellen
Methoden nimmt oder ähnliches Teufelswerk, fangen die Nachteile an.

Insofern kann es durchaus sinnvoll sein, die kleinen Vorteile
von C++ mitzunehmen, es kostet ja nichts.

Der einzige Mehraufwand ist, die Makefiles hinzufummeln; mein
ursprüngliches Original, das ich irgendwo von hier habe, hat mir
hartnäckig immer den Quelltext mit der Listingausgabe überschrieben.

[Thorsten (Gast)]

Hallo,

es wird wohl vorläufig auf etwas a la EatFruit(FRUIT_BANANA) und 
PaintColor(COLOR_GREEN) hinauslaufen, besser als nichts und Fehler 
fallen immerhin beim Schreiben auf.

Die struct-Lösung ist etwas zu wild für spätere Bearbeiter des Codes, 
und das benutzerfreundliche Verpacken in Makro-Kosmetik führt IME nur zu 
lautstarkem Fluchen bei der Fehlersuche...

C++ auf AVR werde ich mir auf jeden Fall für zukünftige Projekte mal 
ansehen. Dass das mit angemessenem Resourcenverbrauch funktionieren 
kann, war mir bisher nicht bewusst.

Vielen Dank für Eure Antworten!

Grüße,
Thorsten