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