enum eMagicTypes
{
  M_INVALID = 0, // always first

  M_HEAL,
  M_DETOX,
  M_REVIVE,
  ...
  M_FIRE,
  M_WATER,

  NUM_MAGIC_TYPES // always last
};

With stringent compiler flags, I sometimes get warnings like

  warning: comparison between signed and unsigned

as it's considering all of the M_* types to be signed values.

I know that if you were to use #define's, you can append a "U" at the end of the number to force it to an unsigned type:

#define MAX_SPELLS 256U

Is there a way to "force" this on enums? Do I need to manually assign their values (and hence losing half of the reason for using enums in the first place), or can I set the first value to

enum eMagicTypes
{
  M_INVALID = 0U, 
  M_HEAL,
  ...
  NUM_MAGIC_TYPES // always last
};

and all the rest of the numbers become the same type?

Or what about this:

enum eMagicTypes
{
  M_INVALID = -1, // always first

  M_HEAL    = 0U, 
  M_DETOX,
  M_REVIVE,
  ...
  M_FIRE,
  M_WATER,

  NUM_MAGIC_TYPES // always last
};

Would "M_INVALID" be set to a signed value and M_HEAL through NUM_MAGIC_TYPES set to unsigned? Or does M_INVALID simply become the equivalent to
unsigned int M_INVALID = (unsigned int)-1;

Aren't enums supposed to be unsigned values by default?

In C++0x/1x, FWIW, you should be able to do:

enum eMagicTypes : unsigned int {
...
};

In C, it might not be a bad idea to use
static const unsigned int ...
instead, since C won't provide any type safety for enums (beyond warnings of not handling certain enumerants in switches).

The code I'm rewriting is done in C, so I'm following that construct.

I've read this:

However, that was only another programmer whose expertise is questionable in this context.

For C++, MSDN says this:

Further reading gave me this (which sorta repeats the first quote's information):

So should I just always cast the enum value to an unsigned int variable if I want to ensure that it'll be seen as an unsigned?

will I get another

  warning: comparison between signed and unsigned

or will it actually just take the value as though I had explicitly cast it:

unsigned int my_magic = (unsigned int)M_INVALID;

Huh... that second MSDN quote I pasted above said only that it was "C++" without mention of C++0x. I wonder if it's a typo on their side, a quirk of only the MSVC compiler (as in, interpreting the standards to fit only their compiler), or just a little-known C++ feature?

Casting isn't much of a problem; I have to cast all over the place anyway. I'm rewriting most of the code anyway to get rid of as many signed ints as possible, such as:

  --row;
  if (row < 0)
    row = NUM_ROWS - 1;

being converted to

  if (row > 0)
    --row;
  else
    row = NUM_ROWS -1;

As was mentioned in earlier threads, the second method will be more optimized than the first.

The same kind of construct is going on with me adding all of these enums:

  if (magic > M_INVALID)
    --magic;
  else
    magic = NUM_MAGIC_TYPES;

The problem with this, obviously, is that "magic" isn't going to be an enum type: it has to be an integer type. But what I was really hoping to do is get rid if the two-sided tests:

  int magic;

  ...

  if (magic > M_INVALID && magic < NUM_MAGIC_TYPES)
    do_something(magic); // magic is now "valid"

in favor of using only unsigned values, and one-sided tests:

  unsigned int magic;

  ...

  if (magic < NUM_MAGIC_TYPES)
    do_something(magic);

If "magic" were to be assigned to M_INVALID and M_INVALID were set to -1, I guess that this second check would be sufficient, as (unsigned int)-1 is > NUM_MAGIC_TYPES...

If you write your code in a way that takes advantage of the type system as much as possible, instead of fighting it with casts, the compiler will be able to catch more bugs for you.

Sure about that? The first method has less code, and needs only one branch instead of two. Doing --row unconditonally is very cheap, branching is more expensive. Not that I'm an optimization expert, but I'd go with the first one. I could tell you that you shouldn't care about these details until you know they are an actual problem, but I know it's fun, so I won't.

Anyway, a common pattern in C code for selecting what to do based on enum types is using a switch, like this:

As you can see, you don't have to test for invalid values explicitly, you get it for free when using a switch statement.

If you still need to test the value, you can use a macro (or inline function) to shorten your code, and avoid duplicating this test:

#define CHECK_MAGIC(m) ((m) > M_INVALID && (m) < NUM_MAGIC_TYPES)

if (CHECK_MAGIC(magic);)
  /* ok to use this value */
else
  /* bad magic value */

Using unsigned int for this would almost certainly be false economy, especially if it means adding casts. It's higly unlikely to give you any more frames per second, if that's what you're after.

So what's the problem there? Just cast the enum value to unsigned.

Anyway, wouldn't you also need to check that the file contains numbers in the first place?

Some of them, yes, using -std=c++0x or -std=gnu++0x.

Or just use int's and compare for range. And write a macro for that if it is too much typing.

And if you get "signed to unsigned" warnings, think about it whether your code is not indeed in error because of those.

That's about what I've been doing. But it's hard to use an enum type when reading in from disk (see highlighted line 618 above), since there's no way that the compiler can validate that the value read in is okay.