enum class - Kapselung ?

[Veit D. (devil-elec)]

Hallo,

hängt zwar mit einem Arduino Core Package zusammen, dass eigentliche 
Problem bzw. Frage dreht sich dennoch um C++ unabhängig von Arduino, 
deshalb frage ich mal hier.

Im verwendeten DxCore Package für AVRxDB Controller ist bspw. der Name 
B1 schon definiert

#define B1 1

Jetzt wollte ich ein enum anlegen mit Namen für meine Sensor Boards.

enum class HallSensorName {A1, B1, B2, C1, C2, C3, D1, D2, D3, E1, F1, NumberOfSensors};

bzw.

namespace HallSensoren {
  enum class HallSensorName {A1, B1, B2, C1, C2, C3, D1, D2, D3, E1, F1, NumberOfSensors};
}

Egal ob ich enum class oder zusätzlich in namespace 'HallSensoren' 
einkapsel erhalte ich

error: expected identifier before numeric constant
#define B1 1

Was ich nicht verstehe, weil class und namespace schränken doch die 
Sichtbarkeit ein. Es dürfte doch zu keinem Konflikt kommen. Hängt das 
mit dem #define und dem Präprozessor zusammen? Wenn ja, gibt es eine 
Lösung ohne das ich meine 'Enumeratoren' verstümmeln muss?

[Sebastian W. (wangnick)]

Veit D. schrieb:
> Hängt das mit dem #define und dem Präprozessor zusammen?

Ja. Der Präprozessor ersetzt rein textuell.

Veit D. schrieb:
> Wenn ja, gibt es eine Lösung ohne das ich meine 'Enumeratoren' verstümmeln muss?

#undef B1

LG, Sebastian

[Oliver S. (oliverso)]

#define stammt aus dem Pleistozän der Programmiersprache. Der 
Preprozessor ersetzt damit stumpf die eine Zeichenkette mit der anderen, 
egal, was da für neuzeitliche C++-Spielereien drum herum stehen.

Es hilft nix, B1 kannst du dein enum nicht nennen, wenn du auch das per 
define definierte brauchst. Wenn nicht, hilft ein an strategisch 
passender Stelle platziertes #undef.

Oliver

[Veit D. (devil-elec)]

Hallo,

alles klar, Danke Euch.

[Rolf M. (rmagnus)]

Veit D. schrieb:
> Was ich nicht verstehe, weil class und namespace schränken doch die
> Sichtbarkeit ein.

Die Sichtbarkeit des enums ja, aber die des #define nicht.
Aus:

#define B1 1

enum class HallSensorName {A1, B1, B2, C1, C2, C3, D1, D2, D3, E1, F1, NumberOfSensors};

macht der Präprozessor erst mal:

enum class HallSensorName {A1, 1, B2, C1, C2, C3, D1, D2, D3, E1, F1, NumberOfSensors};

Und das bekommt dann der eigentliche Compiler zu Gesicht. Der kann aber 
mit der numerischen Konstanten 1 als Name eines Enum-Elements nichts 
anfangen und will einen Identifier haben, wie auch die Fehlermeldung ja 
sagt.
Und das passiert nicht nur bei der Definition, sondern auch bei jeder 
Anwendung von B1.

[Veit D. (devil-elec)]

Hallo,

genauso hatte/habe ich es verstanden. Danke auch dir.

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> Wenn ja, gibt es eine
> Lösung ohne das ich meine 'Enumeratoren' verstümmeln muss?

Herzlichen Glückwunsch: Du bist nun über einen der beiden Hauptgründe 
(un-scoped, un-typed) gestolpert, warum man den Präprozessor besser 
nicht (so unbedacht) einsetzt.

Die Lösung wurde ja schon genannt.

[Manfred M. (bittbeisser)]

Versuche doch mal dein enum wie eine eigene Classe zu behandeln. Bei mir 
funktioniert folgendes

class
Read_File {
  public:
    enum    cb_reason { none, new_object, new_data, end_object }; // access with: Read_File::xxx
...

und dann der Zugriff, etwa so:

...
    Read_File::cb_reason reason = fileloader->reason();
...
    switch( reason ) {
        case Read_File::new_object:
            obj_ptr = mwp->catalog->new_object();
            break;
...

Da wird in einer Callback Funktion der Grund für den Callback 
ausgewertet.

[Veit D. (devil-elec)]

Hallo,

ich vermute du vergisst den allmächtigen Präprozessor. Ich hatte mich 
entschieden das ich die Enumeratoren anders benannt habe. Man muss es 
nicht unnötig kompliziert machen. ;-)

[Rolf M. (rmagnus)]

Veit D. schrieb:
> Ich hatte mich
> entschieden das ich die Enumeratoren anders benannt habe. Man muss es
> nicht unnötig kompliziert machen. ;-)

Letztendlich kam daraus ja daraus die Konvention, Alle Makro-Namen (und 
nur die und nichts anderes) komplett groß zu schreiben.