Re: [Boost-users] non nullable smart pointers

Subject: Re: [Boost-users] non nullable smart pointers
From: Emil Dotchevski (emil_at_[hidden])
Date: 2008-11-14 22:23:38

On Fri, Nov 14, 2008 at 6:16 PM, Brendan Miller <catphive_at_[hidden]> wrote:
> I'm also aware of a number of problems with the shared_ptr
> implementation, specifically that it creates a second allocation for
> the counter (the counted body problem)

Using make_shared avoids the separate allocation for the control block.

Shared_ptr frees the user from having to know (or care) about how the
object instance was allocated, how many (if any) allocations were
made, etc. Optimizing allocations is as easy as supplying a custom
allocator to shared_ptr when the object is first created.

> and that it always does
> synchronization, which might have performance overhead for single
> threaded code

In single-threaded builds, no synchronization is done. In
multi-threaded builds, on most platforms shared_ptr uses atomic
instructions for mutex-free management of the counters.

In theory managing the refcounts is a significant overhead but in
practice I'm yet to see this overhead cause me any real issues.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode