Question about "enums"

[mdh]

In one of the answers to a K&R exercise, the first couple of lines are:

enum loop { NO, YES};
enum loop okloop=YES;

I get the first line, but not the second.

Sorry about the LOL question.

Thanks in advance

[Keith Thompson]

jacob navia <ja***@jacob.re mcomp.fr> writes:

Keith Thompson a écrit :

Since the C standard allows that, code that does it isn't wrong. It's
perfectly legal, and has well-defined semantics, to assign a value to
an enum object that isn't one of the constants defined for the type
(at least as long as the value is between the lowest and highest
values).
For example:
enum foo { FIRST = 0, LAST = 999 };
enum foo obj;
for (obj = FIRST; obj <= LAST; obj ++) {
...
}
Disallow this usage, and you'll break existing valid code.

Why do not use "int"?

Why use an enum when its value is just an int???

For example:

enum foo { FIRST = 0, LAST = 999 };
int obj;
for (obj = FIRST; obj <= LAST; obj ++) {
...
}

Id enums are of any value then at all times the value of an enum
object must be in the legal values of that enum!

If not there is no use actually besides replacing a #define...

Enumerated types have a number of advantages over #define. They
automatically assign unique values to each of a sequence of names; you
can do that manually with macros, but it's inconvenient. They're
scoped; macros are visible from the point of definition to the end of
the translation unit. And the compiler takes care of choosing a type
that fits all the specified values.

Certainly the code you suggest is perfectly valid, and probably better
than the example I presented. And if I were designing a new language
from scratch, enums would be distinct types, and there would be no
implicit conversions between enums and integers.

Although C's definition of enumerated types has some real weaknesses,
I don't think it's broken enough to justify changing it -- at least
not in a language that calls itself "C".

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Vladimir Oka]

Ian Collins opined:

John Devereux wrote:

Ian Collins <ia******@hotma il.com> writes:

John Devereux wrote:

Don't know if it's "broken", but I do regularly make use of this
"feature" of enum. Often I have a situation where a contiguous
range of integers is legal, but some values are special. For
example in an embedded system I might have a lot of (electrical)
signals labelled 0...n. It is quite useful to have the automatic
sequentia l numbering provided by the enum, also to be able to skip
over some "unused", but still valid, inputs.
Nothing wrong with that, I was referring to code that assigned
invalid values to an enum.

But how is the the compiler supposed to *know* they were invalid? In
the code you snipped, I only mentioned the "special" values in the
enum, yet in fact any integer could be "valid".

Sorry if I got carried away with the snippers...

The compiler would know because it knows the legal set of values for
the enumeration. For this to work, math operations on enums will
have to be removed. In my opinion, they don't make sense, given a
set of integers { 1, 5, 7, 9 } what does incrementing a member of the
set do?

Well, for an `enum` it may make sense to "walk" through the list of
allowed values (i.e. `5` + 1 == `7`, in the example above). A bit like
pointer arithmetic, I guess.

I don't see why would that be so useful to make it into the language,
though. And, it would likely break a *lot* of existing code.

IMHO, as they stand `enum`s in C are a bit flawed, but still useful.

--
"How should I know if it works? That's what beta testers are for. I
only coded it."
(Attributed to Linus Torvalds, somewhere in a posting)

<http://clc-wiki.net/wiki/Introduction_to _comp.lang.c>

[August Karlstrom]

Ian Collins wrote:

Bill Pursell wrote:

gcc gives a warning when you do a switch on an enum type, indicating
that you have failed to explicitely specify behavior for any of the
listed cases. I find that very useful.

But not with the following, which I've always considered a huge hole in
the C standard.

enum loop { NO, YES};
enum loop okloop=YES;

void f( enum loop v )
{
}

int main(void)
{
f( 42 );

okloop = 42;

return 0;
}

Compared to other pitfalls in C I think this is a minor one. Note that
the language designer maestro N. Wirth even omitted enumerations in
Oberon (successor to Modula).

Reference: http://www.oberon2005.ru/paper/nw1988d.pdf
August

[Ian Collins]

August Karlstrom wrote:

Ian Collins wrote:

Bill Pursell wrote:

gcc gives a warning when you do a switch on an enum type, indicating
that you have failed to explicitely specify behavior for any of the
listed cases. I find that very useful.

But not with the following, which I've always considered a huge hole in
the C standard.

enum loop { NO, YES};
enum loop okloop=YES;

void f( enum loop v )
{
}

int main(void)
{
f( 42 );

okloop = 42;

return 0;
}

Compared to other pitfalls in C I think this is a minor one.

Not so much a pitfall as a missed opportunity...

--
Ian Collins.

[ais523]

Thad Smith wrote:

Ian Collins wrote:

Thad Smith wrote:

Assigning values other than the constants declared in the enumeration
are not necessarily undefined by the C Standard. The implementation
must assign the enum to an integer type which will hold all the
enumeration constants. It can hold other integer values as well. An
enum type is basically an integer type and can be used as such.

Having said that, I think it is wise, as a good engineering practice, to
use an enum type to hold only the explicitly declared values.

Can you think of any good reason for not enforcing that practice?

Attempts to assign anything other than an enumeration constant defined
for the associated enumeration type or another enumeration variable of
the same type would be a useful compiler or lint warning. Refusing to
translate in such cases would make the compiler non-conforming.

One problem with this is storing an enum in a file. Obviously, there is
no fprintf format code for a user-defined enum, so normally something
like %d is used when portability is needed (first casting to int). When
reading back from the file, the safe and portable way is to fscanf back
into an int, and then assigning the int to an enum. The suggestion
above would make it very difficult to store any enum in a file.

[Ian Collins]

ais523 wrote:

Thad Smith wrote:

Ian Collins wrote:

Thad Smith wrote:

Assigning values other than the constants declared in the enumeration
are not necessarily undefined by the C Standard. The implementation
must assign the enum to an integer type which will hold all the
enumerati on constants. It can hold other integer values as well. An
enum type is basically an integer type and can be used as such.

Having said that, I think it is wise, as a good engineering practice, to
use an enum type to hold only the explicitly declared values.

Can you think of any good reason for not enforcing that practice?

Attempts to assign anything other than an enumeration constant defined
for the associated enumeration type or another enumeration variable of
the same type would be a useful compiler or lint warning. Refusing to
translate in such cases would make the compiler non-conforming.

One problem with this is storing an enum in a file. Obviously, there is
no fprintf format code for a user-defined enum, so normally something
like %d is used when portability is needed (first casting to int). When
reading back from the file, the safe and portable way is to fscanf back
into an int, and then assigning the int to an enum. The suggestion
above would make it very difficult to store any enum in a file.

The same problem exists in C++, a simple cast is the solution.

--
Ian Collins.

[John Devereux]

Ian Collins <ia******@hotma il.com> writes:

John Devereux wrote:

Ian Collins <ia******@hotma il.com> writes:

Nothing wrong with that, I was referring to code that assigned invalid
values to an enum.

But how is the the compiler supposed to *know* they were invalid? In
the code you snipped, I only mentioned the "special" values in the
enum, yet in fact any integer could be "valid".

Sorry if I got carried away with the snippers...

The compiler would know because it knows the legal set of values for the
enumeration. For this to work, math operations on enums will have to be
removed. In my opinion, they don't make sense, given a set of integers
{ 1, 5, 7, 9 } what does incrementing a member of the set do?

Restoring your code:

enum
{
START=000,
REJECT,
QUEUE,
BRAKE,
/*...*/
ALARM=020,
TEST,
NSIGNALS=040
};

turn_on(REJECT) ;
turn_off(TEST);

/* hardware test */
for(i=0; i<NSIGNALS; i++)
{
turn_on(i);
delay();
turn_off(i);
}

I had assumed that i was an int (you didn't show the declaration).

Sorry, yes, i was an int. But turn_off() could be declared a taking an
enum argument. But actually I suppose it could just as well be
declared taking an int, and in fact that is what I do in practice.

I thought your suggestion was that compilers should reject assignments
of values that are not in the enum declaration.

Indeed it is.

So it would be OK to convert an enum to an arbitrary int, but not an
int to an enum type?

--

John Devereux

[Ian Collins]

John Devereux wrote:

Ian Collins <ia******@hotma il.com> writes:

John Devereux wrote:

So it would be OK to convert an enum to an arbitrary int, but not an
int to an enum type?

Yes, that's what I'd like to see. This makes enums appropriate for use
as a type safe function parameter.

--
Ian Collins.