Re: why boost:shared_ptr so slower?
Sam wrote:
That's the general idea -- all reference-counted objects are then
derived from this superclass, virtually, and this is a rough outline of
how I implemented it, except that the virtual superclass's destructor is
not abstract, of course, nor does it need to be.
You do realize that casting from a virtual base class to the actual
object's type can incur a penalty which does not happen with regular
non-intrusive smart pointers?
The actual
increment/decrement operations are the same as with shared_ptr --
compiler-specific instructions that compile down to atomic CPU
operations, so that they are thread-safe.
Increments and decrements are in no way guaranteed to be atomic, and
in some architectures they may well not be. Even if they were, there's
still a huge mutual exclusion problem here:
if (! --m_ptr->m_count) {
delete m_ptr;
}
Guess what happens if another thread executes this same code in
between the decrement and the comparison to null in this thread, and the
counter happened to be 2 to begin with.
I think that shared_ptr could've been a much better implementation, only
with a little bit additional forethought.
Except that shared_ptr was designed to work with any existing type
(including builtin types) without the need to modify that type.