Re: Re: Containers for derived classes

At 02:51 2003-08-11, David Abrahams wrote:
>Daniel Wallin <[email protected]> writes:
>
> > BTW. What's the motivation for holding objects by shared_ptr<..>?
>
>A very good question.  I'm not sure what *motivates* it, but you do
>get certain capabilities which you wouldn't get otherwise.  For
>example, you can convert the Python object to shared_ptr<...>&, and
>then the shared_ptr itself can be modified.  Whether or not that's
>actually useful is another question.

Ok.

>If we'd like to always be able to use your adopt() policy without worrying
>about a runtime failure, I think we'd want to hold all C++ objects by 
>auto_ptr
>instead.

It should be noted here that our implementation differs from yours on how
ownership of the object is handled. In luabind we can tell the object_rep
(kind of like the holder..) to give up ownership, meaning it won't delete
it's held object when collected.
We should share your idea with holders though, but maybe the holder
type could be extended to allow more complex control?

struct holder
{
   virtual void release() { assert(0, "unable to release object"); }
   virtual void* holds(const type_info&) const = 0;
};

This could mean smart pointer types could potentially be used
with adopt()..

>Hmm, I guess there's another case where its important.  If some
>wrapped function *returns* shared_ptr<T>, there's no way to release
>the T object from the shared_ptr.  Therefore you simply want to use
>the shared_ptr in the holder.
>
>So I guess I'm coming to the conclusion that the goal of holding all
>objects by auto_ptr is impractical.  I think it's probably a bad idea
>anyway, since using special smart pointers in holders is
>extraordinarily useful.  See Joel's recent indexing suite work, for
>example.  In fact, all of the return_internal_reference stuff ought
>to be using a special smart pointer holder rather than the funky
>weakref stuff it currently does.
>
> > Doesn't the conversions to/from shared_ptr invalidate the use of
> > the holder?
>
>I don't understand the question, sorry.

You already answered it when you listed some of the reasons of holding
the object with a shared_ptr.

---
Daniel Wallin



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01