sizeof(enum) == sizeof(int) ???

[Derek]

A simple struct

struct Foo {
float x;
char y;
};

The above class occupies 8 bytes on my Win32 system
according to sizeof(Foo). This makes sense because
of the platform's alignment requirements. However,
I can force the struct to be packed by using a non-
standard compiler extension (in my case GCC's "packed"
attribute):

struct Foo {
float x;
char y;
} __attribute__((packed));

Now sizeof(Foo) is 5 bytes. However, when I replace
char y with an enum, say

struct Foo {
float x;
enum { Y } y;
};

the sizeof(Foo) remains 8 whether I pack it or not.
I get the same behavior with MSVC's #pragma pack.

Is an enum always the same size as an int? I thought
an enum was supposed to be as small as needed to hold
all of its values, in this case 1 byte.

[Victor Bazarov]

Derek wrote:

A simple struct

struct Foo {
float x;
char y;
};

The above class occupies 8 bytes on my Win32 system
according to sizeof(Foo). This makes sense because
of the platform's alignment requirements. However,
I can force the struct to be packed by using a non-
standard compiler extension (in my case GCC's "packed"
attribute):

struct Foo {
float x;
char y;
} __attribute__((packed));

Now sizeof(Foo) is 5 bytes. However, when I replace
char y with an enum, say

struct Foo {
float x;
enum { Y } y;
};

the sizeof(Foo) remains 8 whether I pack it or not.
I get the same behavior with MSVC's #pragma pack.

Is an enum always the same size as an int?
No. But the compiler has the final say in that, not you, apparently.
I thought
an enum was supposed to be as small as needed to hold
all of its values, in this case 1 byte.

No, it's up to the implementation to use the type it deems appropriate.
It has to be big enough to hold all the values, but nothing is said that
it has to be no bigger.

Victor

[187]

Victor Bazarov wrote:

Derek wrote:

A simple struct

struct Foo {
float x;
char y;
};

The above class occupies 8 bytes on my Win32 system
according to sizeof(Foo). This makes sense because
of the platform's alignment requirements. However,
I can force the struct to be packed by using a non-
standard compiler extension (in my case GCC's "packed"
attribute):

struct Foo {
float x;
char y;
} __attribute__((packed));

Now sizeof(Foo) is 5 bytes. However, when I replace
char y with an enum, say

struct Foo {
float x;
enum { Y } y;
};

the sizeof(Foo) remains 8 whether I pack it or not.
I get the same behavior with MSVC's #pragma pack.

Is an enum always the same size as an int?

No. But the compiler has the final say in that, not you, apparently.

> I thought
an enum was supposed to be as small as needed to hold
all of its values, in this case 1 byte.

No, it's up to the implementation to use the type it deems
appropriate. It has to be big enough to hold all the values, but
nothing is said that it has to be no bigger.

Actually I do believe enums are usually considered to be an integral
type, so if thats always so, then the subject header is correct.

[Ron Natalie]

Derek wrote:

Is an enum always the same size as an int? I thought
an enum was supposed to be as small as needed to hold
all of its values, in this case 1 byte.

Enum is based on some implementation-defined integral
type with the only caveat in that it shall not be larger
than sizeof(int) unless the enumerators require a larger
range than int can support.

It's perfoectly acceptable for a compiler to use int for
all enums with values that can fit into one.

[Victor Bazarov]

187 wrote:

[..]
Actually I do believe enums are usually considered to be an integral
type, so if thats always so, then the subject header is correct.

Enums considered integral? By whom? How usual is that misconception?
Integral types are (and please memorize this):

signed char |
short int | These are signed
int | integer types
long int |
unsigned char |
unsigned short int | These are unsigned
unsigned int | integer types
unsigned long int |
bool
char
wchar_t

(eleven types total). There are no more integral types. Enumerations
are _compound_ types.

V

[Ron Natalie]

Victor Bazarov wrote:

(eleven types total). There are no more integral types. Enumerations
are _compound_ types.

While enums are not integral types, they are closely allied with them.
Each enum has an "underlying type" which is one of the integral types
which specifies how the enumerators are encoded.

[Victor Bazarov]

Ron Natalie wrote:

Victor Bazarov wrote:

(eleven types total). There are no more integral types. Enumerations
are _compound_ types.

While enums are not integral types, they are closely allied with them.
Each enum has an "underlying type" which is one of the integral types
which specifies how the enumerators are encoded.

I don't contest close relationship or existence of an underlying type.
It wasn't my point.

[Ron Natalie]

Victor Bazarov wrote:

I don't contest close relationship or existence of an underlying type.
It wasn't my point.

My point isn't to argue with you, but to increase the understanding of
the person who posed the original question. While there was nothing
factually wrong with your answer, I felt it an incomplete answer.