Re: [boost] [smart_ptr] release()

Subject: Re: [boost] [smart_ptr] release()
From: Phil Bouchard (philippe_at_[hidden])
Date: 2008-09-09 05:20:58

"Phil Bouchard" <philippe_at_[hidden]> wrote in message 
news:g983c4$ecb$1_at_ger.gmane.org...

[...]

> 1)
> Allocators are designed from bottom up for containers because nodes are 
> allocated in important quantities.  Who cares about 1 or 2 shared_ptrs 
> referring to a block from a local pool?  What happens if you forget 
> passing in the allocator for pointer9?  This will encourage messy code.
>
> People should know what they're doing if they start using allocators in 
> the first place.

[...]

This statement was subjective.  I could not see the usefulness of supporting 
allocators inside shared_ptr if it couldn't be used by containers.  It turns 
out both are necessary:
- release() for generic coding and
- implicit deletion obviously for nested destruction of nodes (stack nodes 
for example)

At the same time release() makes the smart pointer reversible and should 
return the exact same pointer type used by the constructor and assignment 
operator parameters.

-Phil