Why Is Enum Class Preferred Over Plain Enum

Why is enum class preferred over plain enum?

C++ has two kinds of enum:

1. enum classes
2. Plain enums

Here are a couple of examples on how to declare them:

 enum class Color { red, green, blue }; // enum class
 enum Animal { dog, cat, bird, human }; // plain enum 

What is the difference between the two?

• enum classes - enumerator names are local to the enum and their values do not implicitly convert to other types (like another enum or int)

• Plain enums - where enumerator names are in the same scope as the enum and their
  values implicitly convert to integers and other types

Example:

enum Color { red, green, blue };                    // plain enum 
enum Card { red_card, green_card, yellow_card };    // another plain enum 
enum class Animal { dog, deer, cat, bird, human };  // enum class
enum class Mammal { kangaroo, deer, human };        // another enum class

void fun() {

    // examples of bad use of plain enums:
    Color color = Color::red;
    Card card = Card::green_card;

    int num = color;    // no problem

    if (color == Card::red_card) // no problem (bad)
        cout << "bad" << endl;

    if (card == Color::green)   // no problem (bad)
        cout << "bad" << endl;

    // examples of good use of enum classes (safe)
    Animal a = Animal::deer;
    Mammal m = Mammal::deer;

    int num2 = a;   // error
    if (m == a)         // error (good)
        cout << "bad" << endl;

    if (a == Mammal::deer) // error (good)
        cout << "bad" << endl;

}

Conclusion:

enum classes should be preferred because they cause fewer surprises that could potentially lead to bugs.

Which to prefer? An enum class, or a nested unnamed enum type? [duplicate]

Color3 and Color4 are both strong typing

No. Try this:

int x = Color3::red; // ok
int y = Color4::red; // error: cannot convert from 'Color4' to 'int'

The legacy enum is implicitly convertible to an integer, but enum class is it's own type.

As to which to prefer, refer to Why is enum class preferred over plain enum?

Warning C26812: Enum type is unscoped. Prefer enum class over enum

Unfortunately, this warning comes from the header file SFML\Graphics.hpp and the only option is to contact the SFML developers and ask them to fix this warning as suggested by @spectras in the comment section.

There is no solution that I can implement that will solve the warning. However, it is best to disable all the warnings coming from this third party header file by encapsulating it within two pragma statements:

#pragma warning(push, 0)
#include <SFML/Graphics.hpp>
#pragma warning(pop)

With thanks to @Thrasher for providing me with the link in the comment section. Here, is the link:

https://blog.bytellect.com/software-development/c-cplusplus/disabling-warnings-from-legacy-and-third-party-header-files/

c++: OR operator: enum vs enum class? [duplicate]

enum eDogType values are processed as int values, where enum class eDogType values are not (they are processed as values of type eDogType).

So in the first case, the operator | (int, int) is used, whereas in the second case, the operator | (eDogType, eDogType) is needed (but not found).

---

#include <iostream>

enum class  eDogType
{
  eHusk = 0,
  eGold,
  eAus,
  eGerm,
  ePud
};


int main()
{
  eDogType eDog1 = eDogType::eAus;
  eDogType eDog2 = eDogType::eGerm;
  
  eDogType eDog = static_cast<eDogType>(static_cast<int>(eDog1) | static_cast<int>(eDog2));


  std::cout << "Hello World: " << static_cast<int>(eDog) << "\n";

  return(0); 
}

Accessing Enum defined within a class C++

You access enum (class) members like you would access any static member.
Piece::Color::BLACK in this case.

---

In the constructor, you could omit the "Piece" part and just write the following:

Piece::Piece() :
  m_x(UNINITIALIZED),
  m_y(UNINITIALIZED),
  m_color(Color::BLACK)
{}

---

Regarding your hint about this being bad practice: It isn't. You could probably change the int to be a constexpr instead of just const, but whatever you are trying to do with the enum value is totally fine.

---

Related Topics