To const or to enum?

[Steven T. Hatton]

Any opinions or comments on the following? I don't say it below, but I came
out on the side of using enumerations over static constants.

/* I'm trying to figure out the pros and cons of using static const
* int class members as opposed to using enumerations to accomplish a
* similar goal. The use of static constants seems more explicit and
* obvious to me. Unless I assign values to the enumerators, the
* compiler will do it for me. This has the advantage of saving
* keystrokes and digital ink. It has the disadvantage that I have to
* calculate the actual numerical value if I want to know what it
* is. With static constants, it is right there poking you in the eye.
*
* Enumerations support a rudimentary form of type checking. It may be
* useful, but possibly also deceptive. Basically any value that fits
* in the storage location used by the compiler to hold the
* enumerators will convert to the enumeration type, even if it is not
* a value of any of the enumerators. That can be useful for bounding
* a range of values, but it may also lead to a false impression that
* you are using a 'type-safe' value.
*
* The type checking can keep me honest if I want to be. That is, if
* I use the type name as an indicator that a given parameter is
* intended to be of that enumeration type, I can use the enumerators
* by name without explicit type conversions of the form Type(val).
*
* An example of where public static integral constants are used is in
* the w3c DOM recommendations . They serve as a form of poor-man's
* type checking. Each node type is assigned an integral constant
* value with an associated name. The base type of all nodes holds the
* definitions of these constants, and each derived node is assigned
* a named constant identical to one of those named in the baseclass.
*
* A purist may argue that static_cast, or dynamic_cast should be used
* instead, but static_cast only works for types known at compile
* time, and dynamic_cast incurs overhead beyond that of using a
* statically bound integral constant. I may be incorrect regarding
* this last point, but I'm pretty sure of it.
*
*
*/

/*
http://xml.apache.org/xerces-c/Apach...BindingL2.html
*/

/*
DOMNode.hpp:
class DOMNode
{
public:
enum NodeType {
ELEMENT_NODE = 1,
ATTRIBUTE_NODE = 2,
TEXT_NODE = 3,
CDATA_SECTION_N ODE = 4,
ENTITY_REFERENC E_NODE = 5,
ENTITY_NODE = 6,
PROCESSING_INST RUCTION_NODE = 7,
COMMENT_NODE = 8,
DOCUMENT_NODE = 9,
DOCUMENT_TYPE_N ODE = 10,
DOCUMENT_FRAGME NT_NODE = 11,
NOTATION_NODE = 12,
};
*/

/*
* The following is code I created to test certan uses of const and
* enum. I'll be more than happy to see alternatives, or additional
* uses of these syntactic elements.
*/
#include <iostream>
class A {
public:

/*
* We can't use A::EA or A::x before they are declared.
* Therefore the constructor is placed after the declarations,
* which are, in the case, definitions.
*/
/*
A(const A::AE& ae=A::x )
{
if(ae > x)
{
std::cout << "ae > x \n";
}
}
*/

/* Concise, but ugly.*/
/*
static const int X=0,
Y=1,
Z=2;
*/

/* More verbose, but clearer */
static const int X=0;
static const int Y=1;
static const int Z=2;

/* More concise, but more obscure to the untrained eye.*/
enum AE {x,y,z};

/* Placed after declarations (definitions) so I can use them*/
A(const A::AE& ae=A::x )
{
if(ae > x)
{
std::cout << "ae > x \n";
}
}

void f(const AE& ae)
{
if(ae > x)
{
std::cout << "ae > x \n";
}
}

/* How to make a DOM to XML generator, or syntax checker.*/
void g(const AE& ae)
{
switch(ae)
{
case A::x: std::cout << "case A::x \n";
return;
case A::y: std::cout << "case A::y \n";
return;
case A::z: std::cout << "case A::z \n";
return;
}
}

void h(const AE& ae)
{
switch(ae)
{
case A::x: std::cout << "case A::x \n";
return;
case A::y: std::cout << "case A::y \n";
return;
case A::z: std::cout << "case A::z \n";
return;
}
}
};

void i(const A::AE& ae)
{
switch(ae)
{
case A::x: std::cout << "case A::x \n";
return;
case A::y: std::cout << "case A::y \n";
return;
case A::z: std::cout << "case A::z \n";
return;
}
}

int main()
{
A a;
a.f(A::x);
a.f(A::AE(A::Z) );
a.f(A::AE(5));
}

--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Conrad Weyns]

"Niels Dekker - no reply address" <un*****@this.i s.invalid> wrote in message
news:41******** *******@this.is .invalid...

Conrad Weyns wrote:

Here is what I try to adhere to when using enums:

1. Prefix every enum member with the enum name unless the enum
is part of a class in which case it "can" be left out:

enum EColorType
{
EColTypeInvalid ,
EColTypeRed,
EColTypeBlue
};

Your prefix "EColType" differs from the enum name, but I guess that's a
typo...?

Indeed! It's a good job I am not anyone's compiler... :-)

Still, shouldn't we use a little namespace instead? Like
this:

namespace Color
{
enum Type
{
Invalid,
Red,
Blue
};
};

Several years ago I did it this way. These days, if it makes sense to
"group" enums I use a class instead of a namespace.
Namespaces tend to leak into header files, even precompiled headers.
Particularly when they contain entities that are "global" in nature.
I find that the use of :: in code quickly becomes an eye catcher.
EColorRed is unambiguous compared to Color::Red
A matter of code convention in the end, no big deal realy :-)
Regards,
Conrad Weyns

Regards,

Niels Dekker
www.xs4all.nl/~nd/dekkerware

[David Hilsee]

"Conrad Weyns" <we***@online.n o> wrote in message
news:NY******** **********@news 4.e.nsc.no...
<snip>

2. Never ever cast an enum member.
Allways provide a complete (however large) switch to map enum
members to and from other context appropriate values.
This mapping is vital because this is the place where published
values (as read from and written to a data base) are maintained and
de-coupled from the enum.

3. Never ever use enum members in loop indexes and loop limits.

I'd feel free to break either of those two rules if the only place they are
broken is in the component that declares the enum. I've even written a
light wrapper around an enum to make it a little more user-friendly, and
inside of it, both of those rules were broken. I figure it's OK as long as
I'm not chasing down loops and casts in various unrelated modules. It may
be harder to take this approach if it will create dependency issues (e.g.
the database layer must have a mapping for an enum that it did not declare,
or another component needs to map to a DB-related enum), but it still might
be possible to work something out.

--
David Hilsee

[Steven T. Hatton]

David Hilsee wrote:

Well, I meant that as a joke to poke fun at those who might find enums
strange or mildly confusing, but I am surprised that you would say that
enums without explicitly specified values are not immediately
recognizable. I learned about enums when I first learned C, I have never
had to think
twice about them since then. To me, it is immediately recognizable,
easily understandable, and very familiar, even though I do not often use
enums or
see them used in practice. I guess I just found them very intuitive and
simple.

It depends on the situation. If it is simply a question of recognizing that
the symbold in the enum are enumerators, they there should be little
problem. If you are looking through code to find where thefollowing
definitions form the IDE are bound in C++, and what their values are, I
believe listing them as static const (or at least with explicit value
assignments for each enumerator) will be more immediately obvious than the
alternative shown below.

const unsigned short INDEX_SIZE_ERR = 1;
const unsigned short DOMSTRING_SIZE_ ERR = 2;
const unsigned short HIERARCHY_REQUE ST_ERR = 3;
const unsigned short WRONG_DOCUMENT_ ERR = 4;
const unsigned short INVALID_CHARACT ER_ERR = 5;
const unsigned short NO_DATA_ALLOWED _ERR = 6;
const unsigned short NO_MODIFICATION _ALLOWED_ERR = 7;
const unsigned short NOT_FOUND_ERR = 8;
const unsigned short NOT_SUPPORTED_E RR = 9;
const unsigned short INUSE_ATTRIBUTE _ERR = 10;
// Introduced in DOM Level 2:
const unsigned short INVALID_STATE_E RR = 11;
// Introduced in DOM Level 2:
const unsigned short SYNTAX_ERR = 12;
// Introduced in DOM Level 2:
const unsigned short INVALID_MODIFIC ATION_ERR = 13;
// Introduced in DOM Level 2:
const unsigned short NAMESPACE_ERR = 14;
// Introduced in DOM Level 2:
const unsigned short INVALID_ACCESS_ ERR = 15;
// Introduced in DOM Level 3:
const unsigned short VALIDATION_ERR = 16;
// Introduced in DOM Level 3:
const unsigned short TYPE_MISMATCH_E RR = 17;

This form is far less immediately obvious than the IDL definition:
enum{
INDEX_SIZE_ERR = 1, DOMSTRING_SIZE_ ERR, HIERARCHY_REQUE ST_ERR,
WRONG_DOCUMENT_ ERR,
INVALID_CHARACT ER_ERR, NO_DATA_ALLOWED _ERR, NO_MODIFICATION _ALLOWED_ERR,
NOT_FOUND_ERR, NOT_SUPPORTED_E RR, INUSE_ATTRIBUTE _ERR, INVALID_STATE_E RR,
SYNTAX_ERR, INVALID_MODIFIC ATION_ERR, NAMESPACE_ERR, INVALID_ACCESS_ ERR,
VALIDATION_ERR, TYPE_MISMATCH_E RR
}

Even this form is less expressive, though logically (practically) identical
to the IDL:
enum{
INDEX_SIZE_ERR = 1,
DOMSTRING_SIZE_ ERR,
HIERARCHY_REQUE ST_ERR,
WRONG_DOCUMENT_ ERR,
INVALID_CHARACT ER_ERR,
NO_DATA_ALLOWED _ERR,
NO_MODIFICATION _ALLOWED_ERR,
NOT_FOUND_ERR,
NOT_SUPPORTED_E RR,
INUSE_ATTRIBUTE _ERR,
INVALID_STATE_E RR,
SYNTAX_ERR,
INVALID_MODIFIC ATION_ERR,
NAMESPACE_ERR,
INVALID_ACCESS_ ERR,
VALIDATION_ERR,
TYPE_MISMATCH_E RR
}

--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org