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

Discussion in 'C++' started by Derek, Oct 13, 2004.

  1. Derek

    Derek Guest

    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.
    Derek, Oct 13, 2004
    #1
    1. Advertising

  2. 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
    Victor Bazarov, Oct 13, 2004
    #2
    1. Advertising

  3. Derek

    187 Guest

    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.
    187, Oct 14, 2004
    #3
  4. Derek

    Ron Natalie Guest

    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.
    Ron Natalie, Oct 14, 2004
    #4
  5. 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
    Victor Bazarov, Oct 14, 2004
    #5
  6. Derek

    Ron Natalie Guest

    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.
    Ron Natalie, Oct 14, 2004
    #6
  7. 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.
    Victor Bazarov, Oct 14, 2004
    #7
  8. Derek

    Ron Natalie Guest

    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.
    Ron Natalie, Oct 14, 2004
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Schnoffos
    Replies:
    2
    Views:
    1,208
    Martien Verbruggen
    Jun 27, 2003
  2. Hal Styli
    Replies:
    14
    Views:
    1,629
    Old Wolf
    Jan 20, 2004
  3. Spiros Bousbouras
    Replies:
    40
    Views:
    1,482
    Keith Thompson
    Jan 20, 2007
  4. Stargazer

    Re: sizeof(const int *) > sizeof(int *)

    Stargazer, Jun 14, 2010, in forum: C Programming
    Replies:
    14
    Views:
    670
    Ben Bacarisse
    Jul 8, 2010
  5. Ben Bacarisse

    Re: sizeof(const int *) > sizeof(int *)

    Ben Bacarisse, Jun 14, 2010, in forum: C Programming
    Replies:
    12
    Views:
    428
    David Thompson
    Jul 2, 2010
Loading...

Share This Page