Re: Usage of obj->next and obj->next_content

From: Dan Merillat (
Date: 02/20/00

Peter Ajamian writes:
> Dan Merillat wrote:
> >
> > Arn't those two redundant?  From my checking, you can have
> >
> > Person.inventory object->next->next->next
> >                     \      \-contains->next
> >                      \->contains->next->next->next
> >                                     \->contains
> >
> > without ever needing the next_content.  Is that just around for historical
> > reasons?  I'm attempting to simplify somewhat and redo the load/save routin
> >
> > Am I totally off-base or can this be brought in-line?
> Well, if I understand correctly you're asking if the following two
> things would be the same...
> next_content = obj->next;
> var_a = next_content->var_a;
> var_b = next_content->var_b;
> ...and the other way would be...
> var_a = obj->next->var_a;
> var_b = obj->next->var_b;
> well, they will both do the same thing, but on a non-optimizing compiler
> they will probably generate different code.  The first example will
> assign pointer for obj->next to next_content, then use that pointer to
> index var_a and var_b, while in the second example obj->next has to be
> indexed each time before var_a and var_b can be found, resulting in more
> or more complex CPU instructions, the difference becomes more pronounced
> if your indexing obj->next->next, or even more so with
> obj->next->next->next.  It also becomes more pronounced the more you use
> next_content.

Ok, I'm missing something.  How is derefrencing a variable named
next_content more expensive then a variable named next?  One or the other
will end up being null... in fact, ->next is only used if the item
is in a room or inventory.

I'm trying to make sense of the object handling for the load/store routines.
I'd submit changes, but I've got this distinct feeling that it'd break
binary compatability with the existing savefiles if I did.

ascii by 4.0!  :-)


     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     |  |

This archive was generated by hypermail 2b30 : 04/10/01 PDT