Re: CF: Re: apply() cleanup

[Jan Echternach <>]

On Thu, May 11, 2000 at 10:24:29PM -0700, Mark Wedel wrote:
>  get_owner and set_owner need extra logic because objects have a object pointer
> to the owner.  So it needs to verify if what that points to is still the proper
> object, or if the owner has been freed and it should thus free the referance to
> it.

Some references are from other objects, e.g. through op->owner.

>  In the case of apply, I don't think that really works - I am not clear what the
> owner/parent object should be - it would more be like some function is the
> owner, so that doesn't work as well.

Other references are from local variables of type object * in functions.

> best check to see if the object has been freed (op->count is unique or each
> object and will never be reused).  This does not work if op was merged with some

32 bit values overflow in about one year when they are incremented 100
times per second.  If a player is in a room with many spellcasters,
several thousand active objects from cone and ball spells are normal.
I fear that ob_count will overflow some day, provided the server gets
more stable.

> >   op = get_object();   /* or copy_object() or clone_arch() or whatever */
> >   ...  /* customize object, e.g. set op->x and op->y */
> >   put_object_in_map(op);
> > 
> > I like this code because it has a more restrictive structure which
> > makes future design changes easier.
> 
>  I'm not really sure what that really buys over insert_ob_in_map - as I see it,
> the only difference is map is taken implicity from op instead as a passed
> parameter.

The difference was not intentional, I just forgot that parameter.  This
code is at a higher level than the equivalent code using
insert_ob_in_map().  The calls to get_object() (which would be
different in that it increments a reference count implicitely) and the
call to put_object_in_map() (which decrements the reference count)
limit the object's availability to the code between get_object() and
put_object_in_map(), whereas insert_ob_in_map() neither tells the
object management in common/object.c nor the programmer if the object
is going to be used after the insert_ob_in_map().  Many changes to
object handling will only require changing get_object() and
put_object_in_xxx(), or these changes will be easier because most code
follows the simple pattern shown above.  It should make maintenance
easier and prevent bugs.

>  I'm doubtful on the usefulness of referance counts.  it seems that the only
> place where you can really use them is something is when the stack of functions
> get pretty deep - using referance counts would let the object sit around until
> that stack is reduced to a normal level.

As reference counts don't prevent the object from being freed, only
from being reused, they don't give any advantage over op->count here.

>  I'm just a little worried that someone forgetting to put a break_obref will
> cause a difficult to find memory leak down the road.

When I compare reference counts with op->count, I see a few small
advantages (more expressive program structure, no counter overflow
problem) and only two real disadvantages:

  a) Somebody has to implement them.
  -> I would do that.

  b) A break_obref() is easy to forget.

But if you divide references into "permanent" references (by other
objects) and references by local variables, you can check for these
bugs in process_events().  That's why I suggested modifying get_owner()
and set_owner() to maintain a second reference count - the count for
permanent references.

> > How would you handle closed trapdoors, open trapdoors with blocked
> > destination and open trapdoors with free destination consistently?
> > I've stopped at this question because it didn't seem worth changing
> > current behaviour.  All types of exits are placed by the map desinger
> > on the map and should be immediately above the floor or even below the
> > floor.
> 
>  closed_trapdoors - might as well return immediately with no processing since it
> isn't going to change instaneously.

Do you mean to never process objects with FLAG_WALK_ON below a closed
trapdoor?

>  open trapdoors with blocked destination - This is difficult, as it probably
> depends on the blackage.  For example, if it is just a player, a sword should be
> able to fall on top of the player, however we can't have other players (or
> monsters) falling on top of that player.  But if the block is something else
> (like a stone block such that nothing can fall), should return.  But this case
> is probably should just not bother procesing.
>  open trapdoor with open destination - should probably process all objects - it
> makes sense that everything with the player should fall through with them.

I don't care if swords may fall on the top of a player.  The
interesting question is:  If there is a rune of shocking below the
closed/open/blocked trapdoor, should the rune damage a player stepping
on that map square?

-- 
Jan
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to ]