I am thinking Toms Solution might be a better one as std::map has a performance hit as the number of items increase (talking about 100+ vars here) where as enums is resolved at compile time which essentially generate no hit.
Yes, that's true, although 100 variables is still considered not too much, because the performance of the [] operator on a std::map is Log(n), which means 2 operations to access a 100 elements map, and 3 operation to access a 1000 elements map. And you could use the std::unordered_map, which is even faster, because the cost would be 1 operation on average, and Log(n) in the worse case.
But yes, I agree that nothing beats compile time, it doesn't make sense to calculate at runtime something that can be evaluated at compile time. The only case where a map could be useful, might be in a situation where your program doesn't even know the name of the L: variables to be used, for example if they are being read from a configuration file, but that's not very common (perhaps an airplane editor to create animations...)
Thanks though for this map example. It has helped me thought of other users of it already...
the std::map data structure could be used very efficiently for any kind or "radar" or TCAS gauge, anything that would have to update its content at run time, you might use the Object ID returned by Simconnect when querying for all AI around you as the key, and an object containing AI data like position, speed, altitude, etc, as the value, and iterate over the map using the iterator method, to draw the radar/tcas gauge.
That's how the F/A-18 radar is made, of course, and it was very easy to code using the std::map method.
