Re: why boost:shared_ptr so slower?
Sam wrote:
Juha Nieminen writes:
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
A dynamic_cast from a superclass to a subclass, a derived class, only
works if the superclass has, at least, a virtual destructor.
Since the smart pointer was told what the derived class type is, why
would it do a dynamic_cast? What would be the point?
The only difference between a dynamic_cast and a static_cast in this
case is that the former might return a null pointer. If for whatever
reason the smart pointer was told that the object type is A but in
reality it's an object of different type B, you will get buggy behavior
regardless of whether the smart pointer uses dynamic_cast or
static_cast: In the former case you will get a null pointer access, in
the latter memory trashing (as the member functions of the object are
called with the wrong type of object). Either situation is completely
erroneous.
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.
I thought that the whole point of a shared_ptr is so that the referenced
object may be destroyed at the appropriate time. If you don't want the
object destroyed, you don't need a shared_ptr.
You might not have an option. You could have, for example, a function
which takes a boost::shared_ptr as parameter, and thus you have no other
option but to give it one. However, if you don't want to allocate the
object dynamically just to call that function, but instead you want a
stack-allocated object instead, you can still do it, as
boost::shared_ptr supports telling it to not to try to destroy it.