Enums and 16-bit enums

Started by
6 comments, last by Jiia 18 years, 10 months ago
Just a really simple question I was curious about:
enum PortalType
{
  VORTEX,
  BACKHOLE
};
I know these are just hard-coded values, so there is no data type ossociated with it. But I'm wondering if it's possible to declare enum types as anything other than a normal int? For example:
struct SomeStruct
{
  PortalType<unsigned short>  CurrentPortal;
};
The reason I ask is because I have to store a very large number of material enum indices for my terrain. Loading these from file would be twice as fast if I could store the material index in 16-bit. Not a difficult situation to get around, so I'm just wondering if this is possible. I also have another question about enums. I use enums quite a bit to specify integer data types. For example, I use them for character bone indices. There is only one value specified in the enum decleration, BONE_NONE. The actual values are never handled within the game engine. They are loaded from file and passed around, but never hard-coded. The reason I like giving these types of values their own enum type is to avoid associating them with normal integers (without using a cast), and to clearly mark their meaning. Are there better ways to accomplish this, or is this generally acceptable? Thanks for any info.
Advertisement
Nope, Enums are constant values, pretty much like normal #define's

so they cant be associated with variable data.

Raymond Jacobs, Owner - Ethereal Darkness Interactive
www.EDIGames.com - EDIGamesCompany - @EDIGames

Quote:Original post by EDI
Nope, Enums are constant values, pretty much like normal #define's
so they cant be associated with variable data.

But they are associated with an integer type, when you declare a variable with the enum lable. Thanks for the answer, regardless.
Hello Jiia,

Since enum are integer type, there is no reason you can't store them as short and load and use shorts as fields.
You just can't have more then 65535 unsigned or -32768 to 32767 signed.

All the comparesion ops will convert the shorts into the enum type(int most likely) when you compare.

If you declear a enum var, you might need to cast the short into it on assignment, depends on compiler.

Lord Bart :)

Enums are user defined types1

And yes, you can control the size of your enum values. Somewhat.

Quote:Bjarned Stroustrup wrote in The C++ Programming Language1
When all enumerators are non-negative, the range of the enumeration is [0:2k-1] where 2k is the smallest power of two for which all enumerators are within the range. If there are negative enumerators, the range is [-2k:2k-1]. This defines the smallest bit-field capable of holding the enumerator values using the convential two's complement representation. For example:
  enum e1 { dark, light };              // range 0:1  enum e2 { a=3, b = 9 };               // range 0:15  enum e3 { min=-10, max=1000000 };     // range -1048576:1048575


A value of integral type may be explicitly converted to an enumeration type. The result of such a conversion is undefined unless the value is within the range of the enumeration. For example:
  enum flag {x=1, y=2, z=4, e=8}; // range 0:15    flag f1 = 5;          // type error: 5 is not of type flag  flag f2 = flag(5);    // ok: flag(5) is of type flag and within the range of flag    flag f3 = flag(z|e);  // ok: flag(12) is of type flag and within the range of flag  flag f4 = flag(99);   // undefined: 99 is not within the range of flag


The last assignment shows why there is no implicit conversion from an integer to an enumeration; most integer values do not have a representation in a particular enumeration.
...
The sizeof an enumeration is the sizeof some integral type that can hold it's range and not larger than sizeof(int), unless an enumerator cannot be represented as an int or unsigned int. For example, sizeof(e1) could be 1 or maybe 4 but not 8 on a machine where sizeof(int)==4.
By default, enumerations are converted to ingegers for arithmetic operations. An enumertion is a user-defined type, so users can define their own operations, such as ++ and << for an enumeration.


In C, sizeof(enum) will always be 4. But the size may vary in C++, depending on the compiler. Some compilers have command switches that let you specify how it will treat the enumeration, but I honestly don't know the specifics.

1The C++ Programming Language Special Edition by Bjarne Stroustrup, the creator of C++

[Edited by - pragma Fury on June 3, 2005 11:02:05 AM]
So there's no way to simply specify a storage type for a specific instance of an enum variable?

That's really all I needed to know. I really appreciate the extra information.
Quote:Original post by Jiia
So there's no way to simply specify a storage type for a specific instance of an enum variable?

That's really all I needed to know. I really appreciate the extra information.


No, there is no way to explicitly change the type of the enum object.
But nothing is stopping you from placing the value of an enum into a short. (assuming, of course, the value can fit in a short)

Or, I suppose you could do something like:
struct COLOR {   const static short Red=1;   const static short Blue=2;   const static short Green=3;};


For safety, one should always explicitly set the value of enumeration entries anyway. If you let the compiler assign the values, and some time in the future go back and insert a new one, then any code that relied on the original values will break until it is recompiled.
Quote:Original post by pragma Fury
For safety, one should always explicitly set the value of enumeration entries anyway. If you let the compiler assign the values, and some time in the future go back and insert a new one, then any code that relied on the original values will break until it is recompiled.

I've been down that road a few too many times. It's part of my religion to avoid saving enum list indices to file [smile]

It's the most fun when you have about 50+ maps saved with the "old format". So you update the map save function to spit out the new format, but leave the old load function alone until all of the files have been updated. What a nightmare. I strictly save critical data (coordinates and graphical data) to files these days, and leave other stuff for parsers, text files, and scripts.

My Material enum is just a label. It doesn't actually have values defined, other than "invalid". The indices are saved to file, but their values aren't hard-coded. They're entered through a parser file which must specify the index for each entry. It means material indices never get juggled around unless I want to juggle them. I use an enum label to avoid ever representing a material with an integer, because material indices never change within the game, except when they are read from file.

In other words, there's no reason I can't just use a 16-bit int to represent all material indices in the engine. The enum label is just used to clarify and pinpoint the purpose of the data.

Thanks for your help

This topic is closed to new replies.

Advertisement