Equivalent of "using namespace X" for scoped enumerations?

Question

I am using a scoped enum to enumerate states in some state machine that I'm implementing. For example, let's say something like:

enum class CatState
{
    sleeping,
    napping,
    resting
};

In my cpp file where I define a state transition table, I would like to use something equivalent to using namespace X so that I don't need to prefix all my state names with CatState::. In other words, I'd like to use sleeping instead of CatState::sleeping. My transition table has quite a few columns, so avoiding the CatState:: prefix would keep things more compact and readable.

So, is there a way to avoid having to type CatState:: all the time?

---

^{Yeah, yeah, I'm already aware of the pitfalls of using namespace. If there's an equivalent for strongly-typed enums, I promise to only use it inside a limited scope in my cpp implementation file, and not for evil.}

Answer 1

So, is there a way to avoid having to type CatState:: all the time?

Not before C++20. Just as there's no equivalent for having to type ClassName:: for static class members. You can't say using typename ClassName and then get at the internals. The same goes for strongly typed enums.

C++20 adds the using enum X syntax, which does what it looks like.

You can of course not use enum class syntax, just using regular enums. But then you lose strong typing.

It should be noted that one of the reasons for using ALL_CAPS for weakly typed enums was to avoid name conflicts. Once we have full scoping and strong typing, the name of an enum is uniquely identified and cannot conflict with other names. Being able to bring those names into namespace scope would reintroduce this problem. So you would likely want to use ALL_CAPS again to help disambiguate the names.

Answer 2

So the short answer is no, but fortunately this is going to change in a recently finalized feature set of C++20. According to this accepted proposal you will be able to do the following:

enum class CatState
{
    sleeping,
    napping,
    resting
};

std::string getPurr(CatState state)
{
    switch (state)
    {
        using enum CatState;
        // our states are accessible without the scope operator from now on

        case sleeping:      return {};      // instead of "case CatState::sleeping:"
        case napping:       return "purr";
        case resting:       return "purrrrrr";
    }
}

Answer 3

You might consider using a typedef to shorten the qualified names:

typedef CatState C;

Or, if the columns are repetitive in a way that they can be generated easily, you might consider using a macro to generate each row in the table, which can lead to very concise (and easier to read) code.

Answer 4

Nicol's answer is correct: the language is designed to make you always qualify scoped enumerators (except in the enum { } scope itself).

However, here is a technique I came up with for "scoped" enumerators that are unscoped within chosen classes. Technically, the enumerators are unscoped, so they will still convert implicitly to int. (Not "strongly-typed" as you put it.) Nevertheless, in the idiom they are accessed using the scope operator after a true enum name, so syntactically there isn't a difference — and therefore it requires C++11.

#define IMPORTABLE_ENUM( TYPENAME, ... ) \
\
struct import_ ## TYPENAME { \
    enum TYPENAME { \
        __VA_ARGS__ \
    }; \
}; \
\
typedef import_ ## TYPENAME :: TYPENAME TYPENAME;

// usage:
IMPORTABLE_ENUM ( duck, huey, dewey, louie )

duck d = duck::dewey; // can't use unscoped enumerators here

struct duck_madness : private import_duck { // but inside a derived class
    duck who_did_it() { return huey; } // qualification is unnecessary
};

Answer 5

I would also love to have this possibility and I find the limitation quite annoying. It's usually best to have the programmer decide which features he wants to use. Either explicit scoping or the more convenient way. If you restrict the programmer he will either drop the whole feature for the sake of convenience or invent ugly workarounds, like the following template based type safe enum. It will have a some overhead when compiled without optimization.

template<class _Enum>
class type_safe_enum
{
private:
    _Enum m_EnumValue;
    operator int();
public:
    inline operator _Enum() const { return m_EnumValue; }
    inline void operator =(_Enum x) { m_EnumValue = x; }
};

enum _MY_ENUM
{
    Value1,
    Value2
};

enum _MY_ENUM2
{
    Value3,
    Value4
};

typedef type_safe_enum<_MY_ENUM> MY_ENUM;

void TestMyEnum()
{
    MY_ENUM myEnum;
    int x;

    myEnum = Value1; // ok
    // myEnum = Value3; // compilation error
    // myEnum = 0; // compilation error
    // x = myEnum; // compilation error

}