That's the only way. Rooms in ROM are stored in a hash tree (room_index_hash) and you need to iterate through the hash (for( iHash = 0; (pRoom = room_index_hash[iHash]);iHash++)) and then iterate through each of the hash buckets (for( ; pRoom!=NULL;pRoom = pRoom->next))
One option is to replace the hash tree with an array. It's faster, easier, and uses about the same amount of memory.
While it is easier, it uses more memory, assuming a sufficiently large number of holes between rooms. It also ties you in to the model that room identifiers are necessarily numbers. A map approach is far more flexible.
It would be relatively easy to fix things here – what's dumb is the way the list of rooms must be accessed, by directly manipulating the low-level implementation of the data structure.
As usual, implementation and API should be separate, or you end up with dumb access patterns.
Meh. Something stinks about the array idea to me. Its not the most flexible solution. You really don't need to worry about having the o 1 access time. Also I wouldn't worry about using a little extra ram. The lame thing is you'll have to implement a relatively simple data structure that doesn't exist in c.
I don't like the intrusive linked lists. The easiest solution as a user to me would be to use a c++ data structure such as std::map.
09 Aug, 2010, David Haley wrote in the 6th comment:
Votes: 0
The linked lists are there only because the implementation is exposed to the user; hash tables typically use linked lists under the hood after all to implement the buckets. A sane API would make them near-invisible.
Yeah, but I would prefer the linked list not be built into the struct in question.
An actual container object is more appealing to me.
09 Aug, 2010, David Haley wrote in the 8th comment:
Votes: 0
What I mean is that the implementation is (or should be) irrelevant – you wouldn't see it. An "actual container object" of a hash table is all but certainly going to have linked lists under the hood as well – you just won't notice it (which is how things should be).
That implementation under the hood shouldn't be intrusive and define variables on contained objects. . I understand the point your making and its irrelevant to what I'm saying.
09 Aug, 2010, David Haley wrote in the 10th comment:
Votes: 0
Then I don't know what you're saying… you reject an implementation in favor of an "actual container object". What does that even mean? Is the container object not going to have its own under-the-hood implementation details? It sounds like what you want is a sane API, which is what I've been saying all along here……
I'm on my phone so this will be my last in this back and forth.
I'm saying that the implementation under the hood shouldn't be intrusive except with very specific reason.
An example of something not intrusive is a linked list with outside pointers to the data. Not the data itself acting as each node.
I haven't been disputing anything you're saying.
09 Aug, 2010, David Haley wrote in the 12th comment:
Votes: 0
Well, I guess I found what you wrote confusing since it was phrased as disagreement, and you were objecting to the linked lists being part of even the implementation (cf. "built into the struct in question"). If we're in agreement, then all is well in the world… :wink:
One option is to replace the hash tree with an array. It's faster, easier, and uses about the same amount of memory.
Ya know, suggesting this particular implementation in this condition seems a bit… wrong. Considering to cycle through every element of the array, you'd have to go through every spot regardless of the room existing or not. In this case, with the hash tree, you're wasting very few iterations.
Well yes. If the indicies are the vnum. Of course if they aren't then you'd have to search for any lookup.
09 Aug, 2010, JohnnyStarr wrote in the 16th comment:
Votes: 0
Runter's phone is funny :p
IMO, looping through every room in the mud isn't really the best choice. Not that you don't have to peform instructions on many rooms, why not maintain a seperate list of rooms for events. For example, if there are only 4 players logged on, and all 4 are in Midgaard, why would you care about Moria, The Shire, or The Fire Swamp?
In other words, I know C is effcient, and the memory footprint is trivial, but that doesn't mean that you shouldn't develop a more sophistcated update / event system.
If events only occur when players are in a room, it removes the possibility for events to occur regardless of player presence. The world stops being persistent.
Making sure that this will go through every room in the mud, is there a better way to do it? Pulled this from some olc stuff.