[comp.lang.c++] Appropriate use of ENUMs

berczuk@plantagenet.BU.EDU (Steve Berczuk) (05/24/91)

I'd appreciate some comment on the following question that has been
bounding around over here:

2 programmers are working on a given application  and one defines the enum:
enum STATUS{ GOOD,OK,FAIL}

the other:
enum GOOD_STATUS{GOOD,OK}

ther are also (member ) functions defined as follows
  STATUS myFunc(..)
   GOOD_STATUS myOtheFunc(...)

if the the two enumus are compiled together you'll get an error because
GOOD and OK are in 2 enums,
There are a number of ways to resolve this, the cleanest of which is to
define each enum in  a class scope:

   class foo{
 enum STATUS{ GOOD,OK,FAIL}
}

class foo2{
enum GOOD_STATUS{GOOD,OK}
}
 and the particular enum referred to can be resolved using the scoping
operator (with the resulting awkward syntax)

THE QUESTION, HOWEVER, is: is it appropriate to use the enum mechanism
to limit the return values to a
compiler checkable range, or should one enum STATUS be defined to
encompass the whole range of codes
and the return value be limited by range checking. (assume that GOOD,
OK,and FAIl relate to the same status codes)

one arguement is that thischecking of scope of return value using enums
is a feature of the language.

the other is the counter example of a function defined as follows:
   int foo(y)
{
//returns an integer GREATER than 0.
} // ie the fact the the return has a limited range is a requirement
that should be tested.

thanks in advance for your opinions.

jim@tortuga.SanDiego.NCR.COM (Jim (James) Ruehlin) (05/25/91)

In article <5415@atexnet.Atex.Kodak.COM> berczuk@pbtc.kodak.com (Steve Berczuk) writes:
>I'd appreciate some comment on the following question that has been
>bounding around over here:
>
>if the the two enumus are compiled together you'll get an error because
>GOOD and OK are in 2 enums,
>There are a number of ways to resolve this, the cleanest of which is to
>define each enum in  a class scope:

>THE QUESTION, HOWEVER, is: is it appropriate to use the enum mechanism
>to limit the return values to a
>compiler checkable range, or should one enum STATUS be defined to
>encompass the whole range of codes
>and the return value be limited by range checking. (assume that GOOD,
>OK,and FAIl relate to the same status codes)
>
>one arguement is that thischecking of scope of return value using enums
>is a feature of the language.
>
>the other is the counter example of a function defined as follows:
>   int foo(y)
>{
>//returns an integer GREATER than 0.
>} // ie the fact the the return has a limited range is a requirement
>that should be tested.

I'd go with the first argument.  It's cleaner and less prone to error,
since it's checked at compile time rather than making the writer check
it a runtime.

Also, I'd define the enum values to be:
class foo{
public:
	typedef ReturnVals enum {Fail, Good, OK}
};

// if you might use "Bad" instead of Fail, do the following:
#define Bad Fail

This way you only need to worry about one return type (foo::ReturnVals),
and you can use those return values in if() statements easily.  For
instance:

foo::ReturnVals MyFunction()
{
  return (a member of ReturnVals);
}

if (MyFunction())
  cout << "It worked\n";
else
  cerr << "Error";

It just makes it a bit cleaner for my tastes.

- Jim Ruehlin, NCR Corp.
"Call us long distance via AT&T anytime!"