Boost logo

Boost :

From: Emil (emild_at_[hidden])
Date: 2005-04-04 16:49:59


What you are doing is, you have weak_ptr without shared_ptr. You make all
pointers weak, allowing anyone to delete the object at any time, which
automatically invalidates all weak pointers. I'm a game programmer myself, and
I've used similar solution in the past, but now I would use shared_ptr/weak_ptr
instead.

One advantage of the shared_ptr/weak_ptr combination is that it is thread-safe.
You know how important this will be for nextgen console hardware.

Another advantage is that you get to choose between weak and strong pointers;
it is important to be able to express ownership. In other words, shared_ptr and
weak_ptr compliment each other and allow you to pick the proper type of
reference for each situation.

Finally, in your solution, you *assume* that the only way to destroy an object
is operator delete. With shared_ptr, the destruction procedure is abstracted
and hidden from client code. This is a very valuable optimization tool: as soon
as profiling indicates a problem with the allocation/deallocation strategy for
some shared_ptr managed object(s), you can change it without any effect on
client code.

For example, an object representing a puff of smoke from a bullet hitting the
wall can probably be optimized by not using new/delete. If you use shared_ptr
to manage such objects, changing the allocation/deallocation strategy is
trivial and will not break client code. The only way to achieve the same level
of flexibility with your live_ptr design is to disallow new/delete and restrict
everyone to using a pair of create/destroy functions. The problem is, this is
not "built-in" and by the time you figure the allocations are slow you have so
many new/delete calls that it is a major hassle to do something about it. Using
shared_ptr gives you this extra peace of mind knowing you're in control even if
you didn't know you need it.

Also note that with your live_ptr, deleting an object needs linear time to the
number of live live_ptrs. With shared_ptr/weak_ptr, the time it takes to
destroy the managed object is independent of the number of live weak_ptrs
(though I should say you can implement live_ptr semantics with const time
delete as well.)

Emil


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk