Compare enum types to...

[slot]

Is it possible to compare "enum" types to basic types like "unsigned short"
type at all? Thanks!

 

[Victor Bazarov]

Is it possible to compare "enum" types to basic types like "unsigned short"
type at all? Thanks!

What do you mean by "compare types"? It's only possible in C++ to
compare _values_. And, if that's what you asked, then yes, it is
possible to compare values of some enum type to an unsigned short,
they will both be promoted to int (in most cases) and then compared.

Victor

 

[Howard]

Is it possible to compare "enum" types to basic types like "unsigned short"
type at all? Thanks!

Certainly! That's probaby more common than using a variable whose type is
actually an enum. (At least it is in my code.) A lot of code is written
like this:

// given an enum something like this:
enum { errNone, errNotFound, errRead, errWrite };

// code uses it like this:
int err = DoSomething();
if (errNone == err)
// continue with more stuff
else
// do something with the error value

-Howard

 

[Victor Bazarov]

Certainly! That's probaby more common than using a variable whose type is
actually an enum. (At least it is in my code.) A lot of code is written
like this:

// given an enum something like this:
enum { errNone, errNotFound, errRead, errWrite };

// code uses it like this:
int err = DoSomething();
if (errNone == err)
// continue with more stuff
else
// do something with the error value

What is the advantage of your approach above versus

enum ErrCode { errNone, errNotFound, errRead, errWrite };
...
ErrCode err = DoSomething();
...

? Yes, your 'DoSomething' function now has to return ErrCode, otherwise
the initialisation of 'err' won't compile without an explicit cast, but
isn't that the whole point of type safety?

What if I just add 'errBadCmd' right between 'errNone' and 'errNotFound'?
The whole system suddenly stops working, doesn't it? Not in my case. If
ErrCode is used everywhere, then the module that contains 'DoSomething'
would have to be recompiled, but at least it will keep the values in sync.

Victor

 

[Howard]

What is the advantage of your approach above versus

enum ErrCode { errNone, errNotFound, errRead, errWrite };
...
ErrCode err = DoSomething();
...

? Yes, your 'DoSomething' function now has to return ErrCode, otherwise
the initialisation of 'err' won't compile without an explicit cast, but
isn't that the whole point of type safety?

What if I just add 'errBadCmd' right between 'errNone' and 'errNotFound'?
The whole system suddenly stops working, doesn't it? Not in my case. If
ErrCode is used everywhere, then the module that contains 'DoSomething'
would have to be recompiled, but at least it will keep the values in sync.

Victor

I never suggested my example was a "good" approach. I simply said integers
are compared against enum's quite often, and gave a legal, and simple,
example.

So why is "my" code filled with integers instead of enum's? It's because
the third-party APIs and SDKs declare their functions using intege types.
So I'm stuck using them. And most of my code is interacting with those, so
I'm pretty much stuck with it.

Also, many of those function calls use integers because the enumerations are
done by us, the developers of the end-user software, simply as a convenient
way to list, for example, IDs for all our controls in a music device. We're
free to use constants, enum's, or even literals, but enums are easier to
declare. SInce they (the API/SDK designers) don't care how we're going to
eventually define the values, they simply accept and return integers, which
have no restrictions on them (aside from range).

(Good points, though.)

-Howard