Cornstalks has done a good job explaining my reasoning, which I failed to add in my post because I was typing it on my phone. fastcall22's solution works, and that's fine. Run with it.
But not every enumeration is guaranteed to start from 0 or be contiguous. And just because this one is typical doesn't mean it will necessarily remain so for all time (although it may). There have been plenty of times when I made some apparently innocuous changes to code and end up breaking other bits of code here and there that assume the implementation of the bit of code that was originally changed. Hence my recommendation. I'm okay with not everyone agreeing with me ;)
Basic arrays are a part of the language, so I'm not going to say never use them. But I prefer an appropriate stl container wherever possible.
How can I improve this code? (C++ enums)
Data driven design, people. Why hard-coded these? I recommend a hybrid of fastcall22's and Dawoodoz's approaches.
Author
It seems to me like a data driven approach works best when you have a well defined engine component and logic/data component that are planned out ahead of time and a fixed interface between the two. Whereas here, I've got a sprawling multigenre project with no real planning. Actually the entire game is hardcoded, though recently I've experimented with writing scripts to generate the code associated with level data.
One thing I could do is use forward declaration of enums to reduce recompilation, but I'm still using gcc 4.4.1 as I'm a windows noob and don't really know how to mess around with installing other versions of mingw.
One thing I could do is use forward declaration of enums to reduce recompilation, but I'm still using gcc 4.4.1 as I'm a windows noob and don't really know how to mess around with installing other versions of mingw.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
