Enum scoping issues

Question

I try to keep things as local as possible, so I put enums at class scope, even if they are shared between two classes (I put it in the class that "goes better" with it.) This has worked out great, but I recently ran into an issue where a circular dependency will occur if I put the enum at class scope.

The enum is going to be a constructor argument for multiple classes, and the class it is in (and the class that makes the most sense for it to be in) includes those classes. Thus, it isn't possible to use the enum as a constructor argument for the classes included because it will result in a circular dependency.

Would it be better to just put this enum in its own header file, and if so, should I put all of the enums in the header file to be consistent? Are there any other solutions to this issue (that are logical)?

Solution 1

if the enum is used by multiple classes then i would say it does not really belong in the definition of a single class but in the namespace in which those classes reside.

that is unless the enumeration is being passed through one class to the constructor of another in which case it may make more sense to instantiate the enum dependant class seperately and pass it in as a parameter to the constructor of the containing class.

Solution 2

Since C++11, you can use an enum class (or enum struct - the same thing, declared differently), where the enum values are scoped to the enum's name. For example, here is a valid C++11 declaration.

enum class token_type {
    open_paren,
    close_paren,
    identifier
};

To access the values of the enum, however, you must scope it correctly using the :: operator. Hence, this is a valid assignment in C++11:

token_type type = token_type::close_paren;

But this is not:

token_type type = close_paren;

This solves the naming conflict, and means you don't have to use container namespace or struct just to stop the scope of the values leaking to where they shouldn't. This means that the following enum can exist in the same scope as token_type:

enum class other_enum {
    block,
    thingy,
    identifier
};

Now the two values called identifier in the two different structs will not interfere.

Solution 3

I use a variant of what Michael and Roger do:

namespace Color
{
   enum Type
   {
      red,
      green,
      blue
   };
};

void paintHouse(Color::Type color) {...}

main()
{
   paintHouse(Color::red);
}

I find Color::Type to be prettier and more self-documenting than Color::Color or COLOR::Color. If you find Color::Type too verbose, you can use Color::T.

I don't prefix my enumerated values (i.e. COLOR_RED) because the namespace around the enum effectively becomes the prefix.

I've stopped using the ALL_CAPS convention for my scoped constants because they clash with macros in C libraries (e.g. NULL). Macros aren't scoped in the namespaces they are defined in.

Solution 4

I often put my enums in a namespace to prevent the various enum values from cluttering up the global namespace. I think this is what you're trying to do by putting them in a class. But if they don't 'fit' well in a class, a namespace works pretty much just as well for this purpose:

namespace FooSettings
{
    enum FooSettings
    {
        foo,
        bar
    };
}
typedef enum FooSettings::FooSettings FooSettingsEnum;


int main()
{
    FooSettingsEnum x = FooSettings::foo;
};

I have an editor snippet that builds the outline for a new enumeration given just it's name, including the

typedef enum FooSettings::FooSettings FooSettingsEnum;

line that creates a typedef so it's a tad more readable to declare variables with the enumeration's type.

I suspect that Stroustrup would have made enumeration value names scoped to the the enumeration if he had the opportunity, but C compatibility forced his hand (this is just speculation - maybe one day I'll look in D&E and see if he mentions anything).

Solution 5

I agree with Emile. Another option if you are using C++98 is to use struct instead of namespace, as follows

struct Color
{
   enum Type
   {
    red,
    green,
    blue
   };
};

I prefer it since ideally I would use a namespace to represent a module that contains multiple classes, rather than just scoping an enum ...

View more solutions

Comments

[Anonymous]

Enums can't be forward declared.

[Logan Capaldo]

And even if you could, you can't forward declare nested types. Or rather, you can't forward declare a nested type without having the definition of the nesting type.

[Matthieu M.]

I personally prefer a struct than a namespace because a struct is then manipulable from templates.

[Michael Burr]

@Matthieu - Using a struct simply never came to mind. I can't say I've missed not being able to manipulate the enums with templates, but I certainly see no downside to using a struct to wrap the enum scope either. Yet another good idea for me to use. Thanks.

[Emile Cormier]

I'm now considering adopting Matthieu M's suggestion of using struct instead of namespace to be able to pass it as a template parameter. However, I can't think of a reason why I'd pass Color instead of Color::Type as a template parameter.

[Permaquid]

I tried encapsulating enums in a namespace and also in a struct, and some things work better with a struct. So I often do the following: struct MyEnum { enum Values{a, b}; }; typedef MyEnum::Values MyEnum_t; Now I can use MyEnum_t to refer to the enum as a type, and MyEnum::a, MyEnum::b to refer to its members as if the enum were an aggregate type. I experimented a while before choosing the particular naming conventions here and I have over time found the above to be as good as I can do.

[Tom Galvin]

As a historical note, since C++11 you can forward-declare an enum class (or enum struct), but these are distinct from old-style enums.

[Emile Cormier]

I now use C++11 scoped enumerations, but I hope this answer is still useful for those constrained to C++98/03.

[Andrew]

yayyyy . . . . .