[boost] Re: Yet another smart pointer type: a new library proposal

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