Verschiedene typedef enum als unterschiedliche Datentypen behandeln?

ja, indem man C++ nimmt

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

1

typedef struct 

2

{

3

  uint8_t value;

4

} color;

5

6

color white = { 0 };

7

color red   = { 1 };

8

color blue  = { 2 };

9

10

void foo( color col )

11

{

12

  if( col.value == white.value )

13

    ...

14

}

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.

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.