Preventing casting ints to enums in C++

Question

Suppose we have

enum class Month {jan, feb, mar, apr, may, jun, jul, aug, sep, oct, nov, dec};

Each value is an int, 0 to 11. Then I expect variable of type Month to hold only these enumerated values. So here's the only OK way to create a variable:

Month m = Month::may;

But here are some other ways that language allows:

Month m1 = Month(12345);
Month m2 = static_cast<Month>(12345);

which is somewhat disappointing. How do I allow only the first way? Or how do people cope with poor enums in C++?

Answer 1

How do I allow only the first way?

Not possible with enums.

If you want an idiot proof "enum" that cannot be explicitly converted from (possibly invalid) values, then you can use a full blown class instead of an enum. Unfortunately that involves some boilerplate:

struct Month {
    constexpr int value() noexcept { return v; }
    static constexpr Month jan() noexcept { return 0; };
    static constexpr Month feb() noexcept { return 1; };
    static constexpr Month mar() noexcept { return 2; };
    static constexpr Month apr() noexcept { return 3; };
    static constexpr Month may() noexcept { return 4; };
    static constexpr Month jun() noexcept { return 5; };
    static constexpr Month jul() noexcept { return 6; };
    static constexpr Month aug() noexcept { return 7; };
    static constexpr Month sep() noexcept { return 8; };
    static constexpr Month oct() noexcept { return 9; };
    static constexpr Month nov() noexcept { return 10; };
    static constexpr Month dec() noexcept { return 11; };
private:
    int v;
    constexpr Month(int v) noexcept: v(v) {}
};

Answer 2

Your issue could be solved by using a regular class encapsulating a regular enum, like in the following example:

class Month  {
public:
  enum Type {
    jan, feb, mar, apr, may, jun,
    jul, aug, sep, oct, nov, dec
  };
  Month(Type t);
private :
  Type type;
};

then the following would produce compile-time errors:

  Month mm = Month::jan;
  Month m1 = Month(12345);
  Month m2 = static_cast<Month>(12345);

  e.cpp:27:25: error: invalid conversion from 'int' to 'Month::Type' [-
  fpermissive]
      Month m1 = Month(12345);
  e.cpp:26:42: error: invalid conversion from 'int' to 'Month::Type' [-
  fpermissive]
      Month m2 = static_cast<Month>(12345);

There is still a possible, but more complicated scenario to work-around

 Month m1 = Month(Month::Type(12345));

This, however, can be checked dynamically, like this

 Month::Month(Type t) : type(t){
  if (int(t) < 0 || int(t) > int(dec)) {
      throw "error";
  }
}

Answer 3

Then I expect variable of type Month to hold only these enumerated values

Then you have misunderstood what enums (even scoped enums) are. They give you convenient names for some values of the underlying type (and, in the case of scoped enums, prohibit implicit conversions from that type). They do not restrict an object to those named values, nor are they intended to. If you want to do that, create a class with validation routines in anything that changes its state.

However, generally the overhead of such an approach is not considered worthwhile. Following the usual C++ practice, it is just assumed that you never give your enum a value that you shouldn't. If you did, why? That's a bug: fix it. The prohibition on implicit conversions, provided by scoped enums, should make these bugs vanishingly unlikely. And if someone goes out of their way to explicitly convert an unnamed value? That's their own fault! Document that the behaviour of the program will then be "undefined" (not per the language but per your own code's API) and move on.

Answer 4

You can't forbid things that the language allows without modifying the language itself. After all, it's perfectly possible to do:

Month m;
int * val = (int *) &m;
*val = -46;

...and nothing will stop you. The key is that people typically simply shouldn't do that, and if they do, they typically have a very good reason for it.

If you want to enforce stronger coding policies, you'll need either a compiler that supports that kind of diagnostics (typically via warning flags, that can often be converted to hard errors) or simply a different language. If that is not acceptable, typically people cope with problems like this one by simply not writing insane code as in the example I posted.