Enum. question?

[dgboult]

Hello,
I've just been learnning on how to use Enumerations as Integers and I'm not sure about somthing.Say I have somthing like this:

enum {FALSE, TRUE} b;
int i;

I answered what I think they are but please tell me if I'm right or not and why.

a)b = FALSE; /*I think this would be 0*/

b)b = i; /* i = 0 now */

c)b++; /*I think this is 1(TRUE)*/

d)i = b; /* i = 1 now */

e) i = 2 * b + 1; /* i = 3 */

 

[rbobbitt]

>enum {FALSE, TRUE} b;
> int i;
>
>I answered what I think they are but please tell me if I'm right or not and why.

>a)b = FALSE; /*I think this would be 0*/

Yes, the first member of an enum is 0, unless set to a different value explicitly.

>b)b = i; /* i = 0 now */

Only if i is at file scope. If i is an auto variable, the contents are indeterminate.

>c)b++; /*I think this is 1(TRUE)*/

Yes, assuming i is at file scope.

>d)i = b; /* i = 1 now */

Yes, assuming i is at file scope.

>e) i = 2 * b + 1; /* i = 3 */

Yes, assuming i is at file scope.


Russ
bobbitts@hotmail.com

http://home.earthlink.net/~bobbitts

 

[SwapSawe]

Yes the answers are perfectly right assuming i is declared as global or it has been initialised to 0 in the begining of the program.


Regards,
SwapSawe.

 

[Lim]

Only I am not recomending to do
b++;
b is not an integer. It has size of the integer but it can not take any other values except that you put in enum declaration.
For example d can not be 3.
It even can work, but potentially lead to problems on some platforms (with optimized code). Compiler should tell you about this.
So:
b=TRUE;
a=b+b;
is Ok, but
b=TRUE;
b++;
is not.

 

[rbobbitt]

No, it's ok to increment enum variables. Enumerated types are guaranteed to be compatible with some integral type, the type of which is implementation-defined. This means that you shouldn't rely on your enumerated type being capable of representing values outside the range of 0-127 (a signed char -- the smallest integral type) if you're concerned with portability.

AFAIK it's ok for an enumerated type to take on a value that is not matched by a member of its set, provided of course that the value doesn't fall outside the range of values of whatever type for enumerated types was chosen by the implementation.

So, the increment of b above is well-defined, particularly because we know that the result of the increment falls within the range of the members of its set.

Note that this is NOT the case with C++, where I believe a cast to int would be required.

Russ
bobbitts@hotmail.com

http://home.earthlink.net/~bobbitts

 

[Lim]

I think it is possible that some optimizators can change the size of enum variable in final binary code to make that size minimum to hold enum values. I can be wrong. But this can lead to such problem as debug version works fine when release doesn't, scary one.
But I am sure it is not a good practice to incriment or do any operation except &quot;><=&quot; with enum variables. In this case you just loosing the main point of enum. In enum you don't have to depend on the real integer value. You never use something like that:
enum a
{
VALUE1 1,
VALUE2 2
};
enum a v;

v=VALUE1;

if (v==1)
{
....
}
always do
if(v==VALUE1)
{
}
The main point - you can add any new values in enum in this case integer value can change, but you code will always work correctly. And it will be much easy to maintain.
Regards.

 

[rbobbitt]

Optimizers can change the code based on the values in an enum. So, for example, an unoptimized version may choose type int to represent an enum type and an optimized version may choose type char for an enum type when it determines that all of the members fall within that range. But, optimized or not, increment operations are defined in C for enums as long as the result doesn't fall outside the range for the type chosen by the implementation.

A *good* use of increment with enums would be something like this:

enum state {
PHASE_A,
PHASE_B,
PHASE_C,
PHASE_D
};

/* ... */

enum state s;

for (s=PHASE_A;s<=PHASE_D;++s) {
switch(s) {
case PHASE_A:
/* do something */
break;
case PHASE_B:
/* do something else */
break;
/* ... */

I agree with you though that someone's missing the point of enums if they have comparisons that use the supposed value of enum members in their code:

enum state a;

/* ... */

if (a==1) { /* huh? */
/* ... */


Russ
bobbitts@hotmail.com

http://home.earthlink.net/~bobbitts