Members - Reputation: 432
Posted 17 March 2012 - 06:37 PM
For example, let's say you parse your UI layout from XML, and create a memory model of the elements. Then later, during gameplay, you want to update a line of text to, say, display the HP of a character the player clicked on. How do you find which element to modify?
The only thing that comes to mind is a string map (std::map<std::string,int>), and have the game code hardcoded to find a particular element by name. But for me, a red flag goes up whenever I think a map is the solution, so I'm curious if this is how others would do it as well, or if there are better ways to lay them out in memory to be easily found from some sort of identifier.
Members - Reputation: 2109
Posted 17 March 2012 - 07:03 PM
The only thing that comes to mind is a string map (std::map<std::string,int>), and have the game code hardcoded to find a particular element by name. But for me, a red flag goes up whenever I think a map is the solution
Why? Sounds reasonable to me, at least in the absence of additional requirements.
Members - Reputation: 2204
Posted 18 March 2012 - 03:52 PM
Every time you add a boolean member variable, God kills a kitten. Every time you create a Manager class, God kills a kitten. Every time you create a Singleton...
Moderators - Reputation: 20749
Posted 18 March 2012 - 04:53 PM
If you allocate these IDs linearly, ie. starting at 0 and counting up by 1, you can use a simple array to hold (smart) pointers to the actual widget objects associated with each control. So your access code looks like:
This is more or less how everybody does it; some people may use reflection instead of an enum, some may use a dictionary/map instead of a flat array, whatever. The point is, you basically have a mapping from one form of ID that your code understands (constant/enum names in this case) to a different form that is represented by your UI data structures (the flat MyControls array in this case) and you're done.
Do whatever feels natural. It's a UI toolkit, a std::map isn't going to kill you on performance or memory usage.