mhyman@hsfmsh.UUCP (Marco S. Hyman) (07/31/89)
This may be more than a question of style....
There are three ways I can define literal values of type int in C++.
Example:
#define lit val
const lit = val;
enum {
lit = val
};
Using anonymous enums to group related constant values appeals to me because
it adds a touch of documentation -- the implication is that the values are
somehow related. Any problems here? What are the pros and cons of the
three methods? Is there some reason for NOT using a particular method?
None of the questions is of real importance but I'm hoping that those of
you that have given the matter some thought will share those thoughts with
the net.
--marc
--
//Marco S. Hyman
//UUCP: ...!sun!sfsun!hsfmsh!mhyman
//Domain: sfsun!hsfmsh!mhyman@sun.com
grunwald@flute.cs.uiuc.edu (Dirk Grunwald) (08/01/89)
there is an advantage to using enums; when examining an enum value using G++, GDB will print the *name* of the enum, not just the value. this makes debugging a little easier, because you don't need to try to recall what the enum values mean. -- Dirk Grunwald -- Univ. of Illinois (grunwald@flute.cs.uiuc.edu)
guido@piring.cwi.nl (Guido van Rossum) (08/01/89)
Stroustrup, in his book, says that you shouldn't be using preprocessor
features where the language has corresponding features. This rules out
using #define for simple constants.
(My own question: would this hold for #ifdef'ed code, too? I could do
something like
const debug = ...;
.
.
.
foo()
{
if (debug)
printf("foo called\n");
...
}
but I'm a bit worried about dumb (but otherwise OK) compilers that leave
the code in; e.g., for some C compilers, with -O, the code disappears
but the strings remain in the data segment.)
--
Guido van Rossum, Centre for Mathematics and Computer Science (CWI), Amsterdam
guido@cwi.nl or mcvax!guido or guido%cwi.nl@uunet.uu.net
"You're so *digital*, girl!" -- Neneh Cherry
dan@oresoft.uu.net (Daniel Elbaum) (08/02/89)
In article <1148@hsfmsh.UUCP> mhyman@hsfmsh.UUCP (Marco S. Hyman) writes: :There are three ways I can define literal values of type int in C++. [manifest constants, integral variables of type const, and enumerators of unnamed enumerations] :Using anonymous enums to group related constant values appeals to me because :it adds a touch of documentation -- the implication is that the values are :somehow related. Any problems here? What are the pros and cons of the :three methods? Is there some reason for NOT using a particular method? Hopefully somebody will correct me if I'm wrong. The enum solution creates an unnamed type which is distinct from any other type--in other words, the named integral constants which you'd declare as enumerators are not, strictly speaking, of type int. One ramification of the distinction is that function overloads may be disambiguated on the basis of the expression type, which in the case you describe may actually be a bonus. Another difference is that the enumerators aren't necessarily allowed to take on any legal integer value--just a value which can be promoted to an integer. Your implementation may use shorts, for example. Finally, an enum declaration, like a const declaration, can be used to create local constants: class man_1 { public: enum {poison, meat}; int isfood(int dish) { return(dish == meat); } // dish == 1? }; class man_2 { public: enum {meat, poison}; int isfood(int dish) { return(dish == meat); } // dish == 0? }; -- Spa link snot the temper tent, a few cannery doubt lowed. ({uunet,tektronix,reed,sun!nosun,osu-cis,psu-cs}!oresoft!(dan)@oresoft.uu.net)
paul@gill.UUCP (Paul Nordstrom) (08/03/89)
In article <GRUNWALD.89Jul31232111@flute.cs.uiuc.edu> grunwald@flute.cs.uiuc.edu writes: > >there is an advantage to using enums; when examining an enum value using >G++, GDB will print the *name* of the enum, not just the value. > >this makes debugging a little easier, because you don't need to try to >recall what the enum values mean. >-- >Dirk Grunwald -- Univ. of Illinois (grunwald@flute.cs.uiuc.edu) The Oregon C++ debugger does this as well. -- Paul Nordstrom Gill & Co., L.P. uunet!gill!paul