sizeof(enum)

Edit: No, however, you are guaranteed that the enum is never greater than the size of an int or unsigned int unless it needs the larger range, in which case, it will use a larger integral type I.E. unsigned long or long.

Okay, then you will not be exactly sure how big a enum is?

Many compilers make enums as int size, since that's usually optimal. Many compilers also have an option to make enums as small as possible, so two enums may vary in size depending on their value ranges.

You can enforce a minimum size, as D3D does, by including fake entries that require a certain number of bits to hold the value. For example

typedef enum
{
ME_First,
ME_Second,
ME_Third,
ME_FORCE_DWORD = 0x7FFFFFFF
} MyEnum;

There is nothing stopping a compiler from using a 64-bit word to hold this value.

Quote:

Original post by OleKaiwalker Okay, then you will not be exactly sure how big a enum is?

You will only know its size from sizeof().

What's the point to get the size of an enum anyway?

I use it in a memory mananger.

Quote:

Original post by Raduprv What's the point to get the size of an enum anyway?

For reading and writing them to a file is one example. Personally I use an int when serializing enums, but some might not.

Quote:

Original post by Kibble Quote: Original post by Raduprv What's the point to get the size of an enum anyway? For reading and writing them to a file is one example. Personally I use an int when serializing enums, but some might not.

Just keep in mind that ints do not necessarily have the same size (or byte order) across platforms ...

Isn't this one of those areas where C and C++ differ? Something like C++ being able to choose smaller enum sizes freely whereas C is limited to ints (presumably due to the lack of prototypes).
However I still don't see how C++ could allow different sizes when dealing with forward declared enums.

Consider the following scenario:


How on earth is the compiler supposed to determine the enum's size in the second file?
Maybe you simply can't pass an undefined enum by value at all. I'm sure I've done this before but maybe it was just some odd extension to a C compiler..

edit: Ran some quick tests through GCC. It seems like forward declarations of enums is a non standard extension in C (i.e. it emits a warning in -pedantic -ansi -Wall mode) while using them in function declarations is forbidden in C++. Neighter one allowed me to actually use the type.
I'm pretty sure I've used enums as an opaque type in some old sources, oops!

[Edited by - doynax on December 24, 2004 6:48:49 PM]

Can't verify this right now but from what I remember reading the standard, the choice of the underlying type is implementation-defined and the values must fall in the range of INT_MIN and INT_MAX. Hence, ULONG_MAX/LONG_MIN/LONG_MAX and even UINT_MAX could fail on some platforms.

Wow, I had no idea GCC would actually let you forward declare an enum!!!

That's, I think, a major failing in the language... the inability to forward declare an enum. The natural place to define them is in a header file, which means any function that wants to use that enum needs to #include the enum's header from the header that declares the function! Really bad. Which makes it almost necessary to put the enum in its own header, but that just seems like an unneccessary hassle.

I've said it before and I expected to be called an idiot, but I think it would be very nice to have templated enums.

enum<int> ENormalEnum {...};enum<float>                  //  etc...enum<std::string>            //  this would be cool.enum<std::pair<int, float> > //  weird.

Of course you start to see problems with classes that have non-trivial constructors. And you could probably get this same behavior in other not-as-simple ways... but this just seems like a cool feature :)