No, they cannot be nested that way. In fact, any compiler would reject it.
If not is there an alternative solution?
That mostly depends on what you are trying to achieve (solution to what problem?). If your goal is to be able to write something like A::B::SOMETHING1
, you could just define them within a namespace, this way:
namespace A
{
enum B
{
SOMETHING1,
SOMETHING2
};
enum C
{
SOMETHING3,
SOMETHING4
};
}
While the answer that "you can't" is technically correct, I believe you may be able to achieve the behavior you're looking for using the following idea:
I imagine that you want to write something like:
Fruit f = Fruit::Strawberry;
f.IsYellow();
And you were hoping that the code looks something like this:
enum class Fruit : uint8_t
{
Apple,
Pear,
Banana,
Strawberry,
bool IsYellow() { return this == Banana; }
};
But of course, it doesn't work, because enums can't have methods (and 'this' doesn't mean anything in the above context)
However, if you use the idea of a normal class containing a non-class enum and a single member variable that contains a value of that type, you can get extremely close to the syntax/behavior/type safety that you want. i.e.:
class Fruit
{
public:
enum Value : uint8_t
{
Apple,
Pear,
Banana,
Strawberry
};
Fruit() = default;
constexpr Fruit(Value aFruit) : value(aFruit) { }
#if Enable switch(fruit) use case:
// Allow switch and comparisons.
constexpr operator Value() const { return value; }
// Prevent usage: if(fruit)
explicit operator bool() const = delete;
#else
constexpr bool operator==(Fruit a) const { return value == a.value; }
constexpr bool operator!=(Fruit a) const { return value != a.value; }
#endif
constexpr bool IsYellow() const { return value == Banana; }
private:
Value value;
};
Now you can write:
Fruit f = Fruit::Strawberry;
f.IsYellow();
And the compiler will prevent things like:
Fruit f = 1; // Compile time error.
You could easily add methods such that:
Fruit f("Apple");
and
f.ToString();
can be supported.
Best Answer
Yes,
Foo::Red
will work fine.using enum E
behaves as, from [enum.udecl]:And the standard contains an example of exactly this case:
Note however that there is some controversy around the particular spelling for this feature.
enum E
is what's known as an elaborated type specifier (much likeclass C
orstruct S
). Typically, elaborated type specifiers behave exactly the same was as their underlying versions. Elaborating is just meant to disambiguate, and you rarely need to disambiguate, so you wouldn't see it very often. However, in this particular case,using enum E
andusing E
actually mean wildly different and wholly unrelated things. So keep in mind that there is a chance that this feature may not yet actually make C++20, despite currently being in the working draft and even having been published in the CD. As such, it's unlikely that compilers will implement this feature until they're sure it's necessary to implement (C++20 isn't exactly lacking in work for compiler writers...)