Enum wird vom Compiler angemeckert ....



  • Hi Leuts,

    kann mir mal einer sagen warum diese Enum
    enum Farbe {ROT, GELB, GRUEN, BLAU };
    vom Complier (Visula Studio 2008 express) akzeptiert wird, diese
    enum Farbe {MTM, GELB, GRUEN, BLAU };
    aber angemeckert wird? Dabei ist es egal ob jetzt MTM oder ABC steht ....
    Der Compiler meint
    loader.h(8) : error C2143: Syntaxfehler: Es fehlt '}' vor 'Konstante'
    loader.h(8) : error C2143: Syntaxfehler: Es fehlt ';' vor '}'
    loader.h(8) : error C2059: Syntaxfehler: '}'

    Ich möchte verschiedene Ladegerätehersteller in einer Enum definieren, kriegs aber nicht hin:
    MTM, HEIDEN, DEUTRONIC_ALT, DEUTRONIC_NEU



  • Vermutlich ist MTM irgendwo als Makro definiert.



  • Es empfielt sich generell, nur Makros großzuschreiben, um solche Fehler zu vermeiden.

    Gruß Kimmi



  • die anderen Worte mag er auch nicht.



  • 1. Generell keine komplette Großschreibung in C++ Code benutzen. Empfehlung:

    enum farbe { gelb, rot, gruen };
    // oder
    enum Farbe { Gelb, Rot, Gruen };
    

    Komplette Großschreibung benutzt man eigentlich nur für Makros. Und Makros sind bekanntlich evil! 😃 Jetzt haste den Salat. 😉

    2. MTM ist wahrscheinlich in einem der Header die direkt oder indirekt benutzt werden, als Makro definiert. Du kannst in einem solchen Fall, falls du Punkt 1 nicht nachgehen willst, ein #undef MTM machen:

    #undef MTM
    enum Farbe { MTM ...};
    


  • hast Du mir geholfen, danke für den Hinweis.
    Das Problem war dass ich die Header-Datei mit der Definition mehrfach includiert habe, ohne das #pragma once zu benutzen

    THX



  • Grieko schrieb:

    ohne das #pragma once zu benutzen

    Was dir auch nur beim MSVC hilf, soll heißen, nicht standardgemäß und portabel ist. Wenn du dir nicht 100% sicher bist, dass du das Ganze nie auf einen anderen Compiler portieren willst, benutz "richtige" Includeguards, die jeder Compiler versteht.



  • Artchi schrieb:

    Komplette Großschreibung benutzt man eigentlich nur für Makros.

    Ich schreibe neben Makros auch Konstanten groß, was eine verbreitete Konvention in verschiedenen Programmiersprachen zu sein scheint. Ich habe mir das angeeignet und nie groß drüber nachgedacht, aber jetzt wo ich es tue, scheint mir das eine ähnlich dämliche Konvention wie die ungarische Notation zu sein.

    pumuckl schrieb:

    Was dir auch nur beim MSVC hilf, soll heißen, nicht standardgemäß und portabel ist.

    Nicht standardgemäß ist richtig, allerdings wird es von einer ganzen Reihe von Compilern unterstüzt, nicht nur von MS.



  • ich schreib konstanten auch groß:

    const int MEINE_TOLLE_KONSTANTE = 0x001;
    


  • Ist zwar schon off topic,
    aber ich schließe mich auch den Meinungen von It0101 und Registrierter Troll an:

    Ich schreibe Makros und Konstanten immer komplett in Großbuchstaben!

    Allerdings schreibe ich vor Makros den Prefix "MAKRO_", also so:

    MAKRO_RGB( 0xF0, 0xF8, 0xFF );
    

    Und Konstanten versehe ich mit einem Prefix "N" (steht für number):

    #define NUI32_MEINE_TOLLE_KONSTANTE  0x1234
    

    (wobei der Teil UI32 nach meiner Definition für "unsigned int 32bit" steht)

    just my 5 cents,
    Martin



  • Mmacher schrieb:

    Und Konstanten versehe ich mit einem Prefix "N" (steht für number):

    #define NUI32_MEINE_TOLLE_KONSTANTE  0x1234
    

    Nein! :p

    Nimm doch für Konstanten const , so machst du sie für den Compiler sichtbar und gibst einen konkreten Typen an. Das hilft dir beim Debuggen, berücksichtigt den Scope und vermeidet gewisse andere bekannte Makro-Probleme, die durch die rein textuelle Ersetzung entstehen. Beispielsweise muss man bei komplexeren Ausdrücken wie verrückt klammern. Bei Instanzen von Klassen kann ein Nachteil entstehen, wenn der Ausdruck jedes Mal wieder ausgewertet wird, anstatt dass einmal eine Konstante existiert und es sich immer um die gleiche handelt.

    Auch von sowas wie "N" halte ich nicht sehr viel - oft stellt der Bezeichner bereits klar, dass es sich um eine Zahl handelt. Aber das muss ja jeder selbst wissen. 😉



  • Nexus schrieb:

    Nimm doch für Konstanten const , so machst du sie für den Compiler sichtbar und gibst einen konkreten Typen an. Das hilft dir beim ...

    Danke für die Info, wieder was dazugelernt... 👍

    Nexus schrieb:

    Auch von sowas wie "N" halte ich nicht sehr viel - oft stellt der Bezeichner bereits klar, dass es sich um eine Zahl handelt. Aber das muss ja jeder selbst wissen. 😉

    Wenn es nur um ganz "übliche" Programmierung geht, gebe ich Dir recht.

    ABER: Wenn Du ein Projekt vorgesetzt bekommst oder nach Jahren etwas weiterpflegen mußt, kannst Du in ihm mit "Find in files" oder "grep" oder "Dateien suchen" in Total Commander dann gezielt nach den Vorkommen von solchen numerischen Konstanten suchen und Dir den ersten Überblick verschaffen.
    Mit regular Expressions kannst Du mit dem Muster "N Großbuchstabe am Wortanfang, restliches Wort in Großbuchstaben" so sehr leistungsfähig suchen lassen, wenn Du erst mal nicht weißt wie die Konstanten genau heißen.

    Martin



  • Mmacher schrieb:

    ABER: Wenn Du ein Projekt vorgesetzt bekommst oder nach Jahren etwas weiterpflegen mußt, kannst Du in ihm mit "Find in files" oder "grep" oder "Dateien suchen" in Total Commander dann gezielt nach den Vorkommen von solchen numerischen Konstanten suchen und Dir den ersten Überblick verschaffen.
    Mit regular Expressions kannst Du mit dem Muster "N Großbuchstabe am Wortanfang, restliches Wort in Großbuchstaben" so sehr leistungsfähig suchen lassen, wenn Du erst mal nicht weißt wie die Konstanten genau heißen.

    Das kann ich nicht ganz nachvollziehen. Wenn du etwas in einer Datei suchst, dann gehst du doch wohl zuerst mal in der Klassen Definition schauen, oder? Und irgendwelche Konstanten kann/sollte man imo irgendwo mehr oder weniger lokal zur Verfügung stellen, anstatt die alle zu verteilen.

    Die Diskussion über ungarische Notation hatten wir hier schon zu Hauf. Ich/viele andere finden die in modernem Code nicht nötig/unsinnig, aber darauf will ich jetzt gar nicht raus, sondern mehr, wo du genau das Problem siehst?


Log in to reply