Re: why boost:shared_ptr so slower?
Sam wrote:
Casting from any superclass to a subclass incurs a penalty
I don't think that's true. If the compiler can see both class
declarations and there is a simple inheritance relation between them
(with no virtual functions in the derived class), the pointer doesn't
have to be modified in any way and this decision can be done at compile
time. The cast will effectively not create any machine code whatsoever.
Except that shared_ptr was designed to work with any existing type
(including builtin types) without the need to modify that type.
Which, of course, is exactly what I stated in my first message in this
thread, and explained what the trade-offs are. Besides, you cannot
assume that you can arbitrarly attach a shared_ptr to some arbitrary
instance of a builtin or a basic type. For all you know, it was
allocated on the stack, and not the heap, or whichever library allocated
it on the heap, might decide to deallocate it, since it's a basic or a
builtin type that the library owns it, despite the fact that you have a
shared_ptr pointing to it.
If you want to use a shared_ptr which points to an object which must
not be destroyed by that shared_ptr, you can tell it. If the object must
be destroyed in some special way (eg. by using some custom allocator),
you can also tell it that.