Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!hubcap!ncrcae!ncr-sd!SanDiego.NCR.COM!tortuga!jim
From: jim@tortuga.SanDiego.NCR.COM (Jim (James) Ruehlin)
Newsgroups: comp.lang.c++
Subject: Re: Appropriate use of ENUMs
Message-ID: <1991May24.183107.16019@donner.SanDiego.NCR.COM>
Date: 24 May 91 18:31:07 GMT
References: <5415@atexnet.Atex.Kodak.COM>
Sender: news@donner.SanDiego.NCR.COM (News Owner)
Reply-To: jim@tortuga.SanDiego.NCR.COM (Jim (James) Ruehlin)
Organization: NCR Corporation, Rancho Bernardo
Lines: 57

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!"