Namespace level enums in c++

Question

Is it a bad practice to have enums in c++ directly at namespace level? I mean not associated with any class? Say if I have an enum and a class that looks something like this,

enum Player { USER, COMPUTER}

class Game {
//Logic of the game.
};

So should I be declaring the Player enum as a member of game class? Should it be private?

Solution 1

With C++11

This answer was originally written in 2011. Now that C++11 support is widely available, the preferred way is to use enum class, as Matthew D. Scholefield points out below:

enum class Player {
    User,
    Computer
};

The enumerated constants must be qualified with the name of the enum when referenced (e.g., Player::Computer).

Before C++11

No, there's nothing inherently wrong with an enum being public. Bear in mind, however, that enumerated constants cannot be qualified with the name of the enclosing enum type. That is, you cannot write Player::USER or similar to refer to the USER constant; they appear directly in the enclosing namespace. As such, it might be a good idea to set a prefix for your constants so that no name collisions occur.

For instance, consider the following declaration:

enum Player {
  PL_USER,
  PL_COMPUTER
}

This is safer, because name collisions are much less likely with the "PL_" prefix. Additionally, it improves code readability by hinting at which enum a given constant belongs to.

Languages like C# and Java have adopted a slightly different approach to enums, where one has to specify both the name of the enumeration and the name of the constant, such as Player.USER. A similar effect can be achieved in C++ by embedding the enum declaration within a namespace of its own. For example:

namespace Player {
  enum Type {
    USER,
    COMPUTER
  }
}

This has the effect of embedding PLAYER and COMPUTER in the Player namespace instead of the global (or otherwise enclosing) namespace. Whether this is a good approach or not is, in my opinion, a matter of preference.

Solution 2

Generally use minimum scope for anything. That makes it easier to understand things.

However, the clarity or lack thereof due to placement of that enum inside or outside a class, is nothing compared to the shouting, the use of ALL UPPERCASE IDENTIFIERS. Reserve those for macros. In Java they're used for constants because Java got its look and feel from C, where it's not so unusual to define constants as macros (because early C didn't have const).

Note that Java does not have a preprocessor, no macros. It's more than a bit silly to take a convention that originated with C, for keeping macros in a separate "namespace", and applying it without understanding to something else so as to be at completely cross purpose with the original intent.

Solution 3

If enum Player is used ...

• just within class Game --> put in private scope
• used by class Game and its children classes --> put in protected scope
• It relates to class Game and being used at various places --> put in public scope
• Nowhere related to Game --> put in global / namespace scope

Solution 4

This is purely a matter of preference; however, I tend to go with Java-like enums in C++:

class PlayerType {
  public:
     enum VALUE {USER, COMPUTER};
     explicit PlayerType(VALUE val) : value_(val) {}

     operator VALUE() const { return value_; }
     bool operator==(VALUE other) const { return value_ == other; }
     bool operator!=(VALUE other) const { return value_ != other; }
  private:
     VALUE value_;
     // Copy and assign intentionally allowed.
};

The reason I tend to do this is that it is not uncommon to need to add additional functionality (such as conversion to/from string representations) later, and so this structure makes it easy to extend.

View more solutions

Comments

[Cheers and hth. - Alf]

Instead of two-character cryptic prefix, consider e.g. struct Player { enum Enum{ user, computer }; };. In a year or two that might be unnecessary as compilers start supporting C++11 features. But until then... Anyway, it's a good idea to reserve ALL UPPERCASE for macros. Many people do that.

[Martin Törnwall]

@AlfP.Steinbach I agree. However, I tend to prefer namespaces to structs for enclosing enums, as introducing a namespace doesn't introduce any new types to the system.

[Cheers and hth. - Alf]

@Martin: I prefer the struct precisely because it introduces a type. That's very convenient (e.g. you can inherit from it). A type does not use memory or anything: it's zero cost.

[James Kanze]

Note that putting the enum in a namespace or a struct not only puts the names of the constants in the namespace or struct, but also the names of the type. So if the client code wants to declare a variable of the type, he must write Player::Type, and not just Type. If you have C++11, you can use enum class Type to put the enum constants into the scope of the enum itself (and inhibit the automatic conversion to int).

[Cheers and hth. - Alf]

@kmac: C++ got it's basic syntax directly from C, not just look and feel. And C++ extended it and changed it, in the tradition of C at the time, which was also very much in flux. In early C the creators often used lowercase macro names. You can see vestiges of that in e.g. assert and errno and so on. The uppercase convention evolved to become dominant as time passed and experience mounted. But it was for the purpose of minimizing name collisions for macros. Java does not have macros, and adopted the convention for its use for defining constants in C. That use is irrelevant in C++.