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)?

Answer 1

You can try to forward declare the enum like this:

enum MyEnum;

Answer 2

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.

Answer 3

You should place the enum outside of any class if it's shared, but you can still scope the enum. Place it in namespace so the enumerators don't "leak", cluttering your project's namespace:

namespace Project { // you already have this, right? :)
  namespace COLOR { // naming styles differ, use what you like
    enum Color {
      red,
      green,
      blue
    };
  }
  using COLOR::Color; // now you can use the type 'normally'

  // examples:
  struct A {
    Color c;
    A() : c(COLOR::red) {}
  };
  void f(Color c) {
    using namespace COLOR;
    // inside this function, we no longer have to prefix COLOR::
    if (c == green) {
      go();
    }
    else if (c == red) {
      stop();
    }
  }
}

Answer 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).

Answer 5

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.