enum class Color : int
{
	Black = 0,
    ...
	White = 15
};

void MyFunction(Color color)
{
	if ((color & ~Color::White) != Color::Black)
    ...

IntelliSense: expression must have integral or unscoped enum type
error C2678: binary '~' : no operator found which takes a left-hand operand of type 'Color' (or there is no acceptable conversion)

Wie kann ich dieses Problem am besten lösen?

Indem du die Operatoren für dein enum definierst.

Er könnte aber auch explizit casten, wenn er sowieso schon auf Ganzzahl-basis damit rechnen will...

Jo klar, mal eben im Code an jeder Stelle refactoren...

Dann stellt sich die Frage, wozu dieser ganze "streng-typisiertes enum" quatsch (Edit) hier gut ist, wenn es eh nur Ärger bringt...

Jo klar, mal eben im Code an jeder Stelle refactoren...

Für jedes popelige enum die ganzen Operatoren zu definieren ist aber auch nicht besser.

Denk doch mal nach du Depp

Hab ich ja. Ich hab nachgedacht, was herausgefunden und es dann geschrieben

Es ist nicht überall besser.

Für jedes popelige enum die ganzen Operatoren zu definieren ist aber auch nicht besser.

Ist ja auch nicht so, als ob sich das durch ein simples Makro vereinfachen liese.

Hacker schrieb:

Hab ich ja. Ich hab nachgedacht, was herausgefunden und es dann geschrieben

Es ist nicht überall besser.

Niemad hat gesagt, dass man jetzt jedes enum durch ein enum class ersetzen soll. DA liegt der Fehler.

Niemad hat gesagt, dass man jetzt jedes enum durch ein enum class ersetzen soll. DA liegt der Fehler.

Genau.
@TE: Wieso hast du überhaupt deine ganzen Enumerationen zu streng-typisierten geändert?

Naja, strongly typed enums haben den Vorteil, dass sie nicht den sie enthaltenden Namensraum verpesten...

?? Dann machst du noch einen weiteren, einzig sie enthaltenden Namensraum..??

namespace Enums
{
    enum meinEnum
    {
        ME_ErstesElement,
        ME_ZweitesElement
    }

  //-..

Im übrigen muss man sich halt entscheiden was einem wichtiger ist, den Namensraum sauber halten oder auf Ganzzahlbasis rechnen können ohne irgendwelche Makros oder anderes gedöns...

Naja, strongly typed enums haben den Vorteil, dass sie nicht den sie enthaltenden Namensraum verpesten...

Genau das war der Grund. Da sie nicht unscoped sind kann ich mir den ganzen namespace Müll sparen, dachte ich zumindest. Leider habe ich immer mehr das Gefühl, dass im Standardisierungskommitee nur noch Ideoten sitzen und die Dinge nicht zu Ende denken. Dieses enum class ist doch somit vollig nutzlos.

dot schrieb:

Naja, strongly typed enums haben den Vorteil, dass sie nicht den sie enthaltenden Namensraum verpesten...

Genau das war der Grund. Da sie nicht unscoped sind kann ich mir den ganzen namespace Müll sparen, dachte ich zumindest. Leider habe ich immer mehr das Gefühl, dass im Standardisierungskommitee nur noch Ideoten sitzen und die Dinge nicht zu Ende denken. Dieses enum class ist doch somit vollig nutzlos.

Das sie den Namensraum nicht verpesten ist gar nicht das essentielle, sondern dass sie sich nicht implizit zu Skalaren konvertieren lassen.

Wenn es dir nur um den Namensraum geht, siehe oben - so kannst du das doch viel eleganter und mit weniger Aufwand lösen. Es ist eher Geschmackssache wieviel Aufwand man für Enumerationen verwendet (@PI: Viel Spaß mit deinem Makro XD).

Die Leute im Standardkomitee wissen schon was sie tun, genau darum sitzen ja auch genau die dort und nicht jemand anderes

(@PI: Viel Spaß mit deinem Makro XD).

#define BITFLAGS_ENUM(enum_type, underlaying_type) \
        bool operator &(enum_type a, enum_type b) \
        {
                return static_cast<underlaying_type>(a) & static_cast<underlaying_type>(b); \
        } \
        \
        enum_type operator | (enum_type a, enum_type b) \
        { \
                return static_cast<enum_type>(static_cast<underlaying_type>(a) | static_cast<underlaying_type>(b)); \
        } \
        ...

enum struct e : std::uint64_t
{
        foo = (1 << 0),
        bar = (1 << 1),
        baz = (1 << 2),
        qux = (1 << 3),
        ...
};

BITFLAGS_ENUM(e, std::uint64_t)

Oh ja, ist ja wirklich unglaublich schwer...

Hacker schrieb:

(@PI: Viel Spaß mit deinem Makro XD).

#define BITFLAGS_ENUM(enum_type, underlaying_type) \
        bool operator &(enum_type a, enum_type b) \
        {
                return static_cast<underlaying_type>(a) & static_cast<underlaying_type>(b); \
        } \
        \
        enum_type operator | (enum_type a, enum_type b) \
        { \
                return static_cast<enum_type>(static_cast<underlaying_type>(a) | static_cast<underlaying_type>(b)); \
        } \
        ...

enum struct e : std::uint64_t
{
        foo = (1 << 0),
        bar = (1 << 1),
        baz = (1 << 2),
        qux = (1 << 3),
        ...
};

BITFLAGS_ENUM(e, std::uint64_t)

Oh ja, ist ja wirklich unglaublich schwer...

Nö schwer nicht... davon war nie die Rede...einfach mehr Aufwand als nötig (wenn du noch arithmetische Grundrechenarten dazu nimmst )

Jo wirklich, ein BITFLAGS_ENUM(bla, fuh) hinschreiben ist wirklich total viel Aufwand. Außerdem: Wieso willst du mit enums rechnen? oO

Ne, nicht das hinschreiben vom Makro. Das definieren (obwohl du das theoretisch nur einmal brauchst und dann CTRL+C/V)... wieso ich mit ihnen Rechen will? gelegenheitlich... ich kann jetzt kein Beispiel nennen SETZ MICH NICH' UNTER DRUCK!

Das definieren (obwohl du das theoretisch nur einmal brauchst und dann CTRL+C/V)

Nö. Stecks in nen Header.

Hacker schrieb:

... wieso ich mit ihnen Rechen will? gelegenheitlich... ich kann jetzt kein Beispiel nennen SETZ MICH NICH' UNTER DRUCK!

Bring ein Beispiel, aber schreib keinen Müll.

wirklich, ein BITFLAGS_ENUM(bla, fuh) hinschreiben ist wirklich total viel Aufwand.

Ich frage mich, warum du fuh brauchst. Das ist fehleranfällig und den Typen bekommst du doch auch durch std::underlying_type<bla>::type .

Bring ein Beispiel, aber schreib keinen Müll.

Ok.

enum Color
{
      black,
      blue,
      green,
      cyan,
      red,
      magenta,
      brown,
      light_grey,
      dark_grey,
      light_blue,
      light_green,
      light_cyan,
      light_red,
      light_magenta,
      yellow,
      white
};

//...

SetConsoleTextAttribute(GetStdHandle(STD_OUTPUT_HANDLE), TextColour + 16 * BackgroundColor);

314159265358979 schrieb:

wirklich, ein BITFLAGS_ENUM(bla, fuh) hinschreiben ist wirklich total viel Aufwand.

Ich frage mich, warum du fuh brauchst. Das ist fehleranfällig und den Typen bekommst du doch auch durch std::underlying_type<bla>::type .

Dass es std::underlaying_type gibt, hab ich noch nicht verinnerlicht. Du hast natürlich Recht, so wäre es besser.

Hacker schrieb:

314159265358979 schrieb:

Bring ein Beispiel, aber schreib keinen Müll.

Ok.

enum Color
{
      black,
      blue,
      green,
      cyan,
      red,
      magenta,
      brown,
      light_grey,
      dark_grey,
      light_blue,
      light_green,
      light_cyan,
      light_red,
      light_magenta,
      yellow,
      white
};

//...

SetConsoleTextAttribute(GetStdHandle(STD_OUTPUT_HANDLE), TextColour + 16 * BackgroundColor);

Mal abgesehen, dass mich Beispiele mit Windoof-spezifischem Code ankotzen, ergibt dein Beispiel doch gar keinen Sinn. Was soll denn bei 2*black rauskommen? Woher weißt du, dass 165*red immer noch red ist?

Hacker schrieb:

314159265358979 schrieb:

Bring ein Beispiel, aber schreib keinen Müll.

Ok.

enum Color
{
      black,
      blue,
      green,
      cyan,
      red,
      magenta,
      brown,
      light_grey,
      dark_grey,
      light_blue,
      light_green,
      light_cyan,
      light_red,
      light_magenta,
      yellow,
      white
};

//...

SetConsoleTextAttribute(GetStdHandle(STD_OUTPUT_HANDLE), TextColour + 16 * BackgroundColor);

Mal abgesehen, dass mich Beispiele mit Windoof-spezifischem Code ankotzen, ergibt dein Beispiel doch gar keinen Sinn.

Selbstverständlich ergibt es Sinn.

314159265358979 schrieb:

Was soll denn bei 2*black rauskommen? Woher weißt du, dass 165*red immer noch red ist?

Deine Fragen ergeben doch gar keinen Sinn, denn 2 * black ist 0 und 165 * red ist selbstverständlich irgendeine Zahl (und wieso zum Teufel sollte die dann red sein!?).

Selbstverständlich ergibt es Sinn.

Nein, tut es nicht. Farben werden üblicherweise als RGB, HSV, CMYK oder andere dargestellt. Aber ein BBGCRMBL_GD_GL_BL_GL_CL_RL_MYW Farbsystem kenn ich noch nicht.

Hacker schrieb:

Deine Fragen ergeben doch gar keinen Sinn, denn 2 * black ist 0 und 165 * red ist selbstverständlich irgendeine Zahl (und wieso zum Teufel sollte die dann red sein!?).

Die Fragen waren vermutlich falsch formuliert. Aber ich bin mal so frei und stelle direkt die fundementalere Frage: Welche interne Repräsentation schwebt dir vor? Das würde mich nun schon sehr interessieren. Am besten implementierst du den *-Operator, gibst jeder Farbe einen bestimmten Wert und schreibst eine Funktion std::array<unsigned char, 3> to_rgb(Color).

Hacker schrieb:

Selbstverständlich ergibt es Sinn.

Nein, tut es nicht. Farben werden üblicherweise als RGB, HSV, CMYK oder andere dargestellt.

Microsoft!
Aber mit 8 Bit kann man kein RGB machen (durch drei geht nicht, und für jeden Farbkanal zwei Bit ist zu wenig).

314159265358979 schrieb:

Hacker schrieb:

Deine Fragen ergeben doch gar keinen Sinn, denn 2 * black ist 0 und 165 * red ist selbstverständlich irgendeine Zahl (und wieso zum Teufel sollte die dann red sein!?).

Die Fragen waren vermutlich falsch formuliert. Aber ich bin mal so frei und stelle direkt die fundementalere Frage: Welche interne Repräsentation schwebt dir vor? Das würde mich nun schon sehr interessieren. Am besten implementierst du den *-Operator, gibst jeder Farbe einen bestimmten Wert und schreibst eine Funktion std::array<unsigned char, 3> to_rgb(Color).

Tut mir leid wenn ich dir jetzt sehr blöde Fragen stelle, aber was heißt "interne Repräsentation"? Wovon?