The enum keyword seems like it would neat and convenient tool for me, except that it doesn't behave the way I'd expect or want...

From this reference (chosen arbitrarily).

To me, this seems backwards. Suppose I had something like this:

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

It seems to me that it would be fairly natural to want to do something like this:
Month this_month = 4;

It's not a big deal that that isn't allowed. What is a big deal is this:
int an_unrelated_number = mar; //lolwut?
I just don't understand why this is allowed! I'd like to use enum, but I don't what my enums to clutter up the namespace in this way.

So my question is this: is there some trick I can use to define an enum, like the Month thing above, without implicitly defining a bunch of constant ints that I won't ever need outside of the Month enum.

Tobias answered this question for me once here, and then again a few days ago here.

The reason for not allowing an implicit int -> enum conversion seems ... reasonable; and axilmar's examples look like they do just what I was asking for. So thanks for all that.

Also, I did a little bit of testing with regard to the enum namespace thing...

enum Day {mon = 0, tue, wed, thr, fri};
//...
{
  int test = tue; // this is allowed, and now test == 1
  Day today = tue;
}
{
  int test = tue;
  int tue = 5;
  int test2 = tue;
  // now test == 1 and test2 == 5; Everything is fine so far
  Day today = tue; // but this is not allowed
}

So the result of all that is that although the enum stuff does hang around even when it isn't wanted, it does a decent job of staying out of the way.

For what I'm doing, I think I'll try axilmar's class thing. (edit - ** see below)

--

type568, I don't think what you said about multiple enum values being the same int value is correct – because of this:

enum Day {mon = 0, tue = 0, wed, thr, fri};

Day today = mon;

if (today == tue)
    cout << "tuesday!";

This code results in "tuesday!" being printed. The point is that although multiple labels can apply to one number, it is still just one number. So this doesn't create a problem for converting ints to enums.

--
[edit]
I'm having some trouble getting that class solution to work. I guess I didn't really understand what I was meant to do. Here's what I've got so far:

Ok, but even with that line commented out, x = Day::mon; is compiled without warnings or errors. Actually I don't understand what would prevent it from being allowed. This 'Day' class, made using the template, has all the properties that struct DAY has and they are all public. So if DAY::mon works, then Day::mon will also work.

I'm trying to achieve what you described here:

If you've done this in your own projects, would you mind posting a complete example? Because although I thought I understood how it worked before, I don't see any way forward now.

Right, that seems fair. But I think an equally fair alternative would be to just treat enum as an int in which some particular values have names. So any int value is allowed by the enum, but not all values have special names. That's how it works in C, and I think it's fine*.

However, I completely understand the reasons behind not allowing implicit conversion from int to enum, and I think the reasons are sensible and fair. I just expected that it would be the same as in C, for consistency, but it isn't.

The main thing I don't like is the other side of things - the fact that the labels can be used outside of the enum (C has the same problem). I want the enum labels to apply only to the enum. I don't see any reason to spew the enum definitions across the entire namespace, and it prevents me from doing stuff like this:

enum Type1 {empty = 0, rock, sand, water, grass};
enum Type2 {empty = 0, road, water, tree, dirt};
// error: conflicting declaration 'water'
// but all I want is for 'water' to refer to 3 when I'm using Type1, and 2 when using Type2. There should be no conflict. 

If I wanted to define a bunch of constant ints, I'd define a bunch of constant ints... like this const int empty = 0, rock = 1, sand = 2, water = 3, grass = 4; // not what I want

In C and C++, enum is just loosely controlled syntactic sugar over an int. The type doesn't mean anything in particular, except that certain values can be accessed by a meaningful name (albeit, the namespace issue pretty much forces the name to be uber long or potentially conflicting). enum types are not very type safe at all. You certainly can't rely on them. They basically provide the programmer with a semantically sensible alternative to magic numbers. Essentially, identical to a set of const ints and an int; except that C++ requires a cast. Requiring a cast is a good thing, but it still isn't something that you can rely on nobody doing. For that it would need to be impossible to cast to an enum type, which would have its own downfalls. Validation is your friend.

Of course! Nobody argues about whether stuff that's obviously necessary should exist.

That's the stuff that needs removing.

Here is the code:

And here is the compiler error:

ah. I understand now. What I had was on the right track but I thought that it would prevent i = Day::MON;, which it doesn't. But it does prevent i = day;.. So it isn't a complete solution to my complaint, but it is an improvement over the usual enum behavior. Thanks for that.

That's meant to be the default initializer of T::VALUE. So it should result in the default value of the enum. Actually, I the line needs to be Enum(typename T::VALUE value = typename T::VALUE()) : m_value(value) {}, I think. I don't really know why it needs the "typename" keyword, but the compiler was complaining without it.

C++0x seems to solve all these problems. If you declare an enum with enum class then it's strongly typed (no conversion from or to integers) and the scope of the values is inside the enum name.

In C#, you can cast any enum back to its underlying integer type without a compiler error; the only thing that's required is that the cast be explicit. The enum behaves exactly as in C++.
Compile and run for your pleasure:

Seriously, the idea is not to make things 120% foolproof. The idea is to provide programmers with tools that prevent them from accidentally doing stupid things. If you want to assign a value to an enumeration variable that's not in the enumeration, you can, but the language makes you jump through a little inconvenient hoop, which should be enough to remind you that you're not supposed to do this unless you absolutely have to (e.g., when reading enum values from a data source that has no notion of enumerations, like a binary file, or when interfacing with a closed API that provides raw integers only).

I'm pretty sure a determined programmer will find a creative way around that, too.