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
es.
> >
> > 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! :-)
--Dan
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT