On Wed, 2006-02-15 at 16:36 -0600, Daniel Wilson wrote: > Nice code, > > If your list grows larger, you could use a hash table or, in such a case, I > would prefer one of the tree structures like AVL. You would have to populate > them at runtime, but that are much faster, especially with large amounts of > entries. > > In this case a tree would be better because you probably also want to > iterate over all entrees alphabetically such as listing all the commands a > client has access too. > > Danni
Not quite. He can iterate alphabetically as well. Also, this tight loop is actually marginally faster than any AVL code (because it avoid pointer dereferencing, which any binary tree implementation would have to do). I say marginally, because the number of CPU cycles that would save you could probably count with your fingers, never mind polydactyly. The point actually is that this is good, _if_ you intend to hard-code it like this. The drawbacks are (1) this cannot be dynamically-updated and (2) you have to manually sort the array when coding. Trees (like AVL trees or what the HL2SDK seems to use, red-black trees) are dynamically updateable, but they have some insertion overhead. (Not much.) Access is for all intents and purposes the same speed. So really, it depends on what you want to do, and how much complexity you're going to bother with. Given that this particular instance is one that doesn't need dynamic insertion/deletion, hard-coding is fine. If you need more complex data structures, though, the handy-dandy CUtl* classes are already pre-written by Valve for your use, and they include hashmaps, trees, dictionaries, etc. _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
