Not true, they allocate nothing until used Whatever broken implementation you had might have done this, but it is not how it is supposed to work.
Actually Spiro's statement was half correct. When you default construct a boost::shared_ptr, no additional control structure is allocated. When you construct it with nullptr, a control structure is indeed allocated, and the deleter is called on that pointer.
Actually we are all entirely correct (except for one reference to how things are supposed to work).
It’s up to the implementation, which is one of the scariest things about it and one of the biggest reasons to stay away (that and the atomic handling of the reference counters).
Whatever broken implementation you had might have done this, but it is not how it is supposed to work.
Actually, it’s the most recent version of the PlayStation Vita SDK, with C++11 support, and is what I am currently using, because what choice do I have?
But the standard doesn’t define implementation details, so there is no real how it is supposed to work, other than by conforming to the functionality specified by the standard.
So it’s reason enough to stay away from shared_ptr in general just because you don’t have guarantees on how it is implemented, but there is one extremely major issue in terms of performance that is true for all implementations (as the standard specifies that multi-threaded access to a shared pointer is built-in) which is also cause to stay away: Atomic reference counting.
Boost and std::shared_ptr are bottlenecks.
That article does not discuss the allocation overhead, but the overhead in atomic increments and decrements necessary for a standard-compliant shared_ptr to adhere to the, “All member functions (including copy constructor and copy assignment) can be called by multiple threads on different instances of shared_ptr without additional synchronization even if these instances are copies and share ownership of the same object,” specification.
All-in-all you don’t really win with std::shared_ptr or boost::shared_ptr.
It’s better to roll 2 of your own (one for single-threaded access and one for multi-threaded access) so that:
- You are sure of the implementation details.
- You don’t waste cycles on atomic operations when not necessary.
L. Spiro