Re: Re: Containers for derived classes

At 13:34 2003-08-12, David Abrahams wrote:
>Daniel Wallin <[email protected]> writes:
>
> > 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.
>
>I plan to adopt that approach, but my point is that it has certain
>limitations because you can never tell a group of sharing shared_ptr's
>to give up ownership.  So you can null out the shared_ptr in the
>holder, but you still have to hang onto something... a shared_ptr, if
>you want to keep the object alive.

Right, given:

void f(A*);
shared_ptr<A> g();

    def("g", &g)
    def("f", &f, adopt(_1))

 > f(g())

wouldn't work, but it could work if the smart pointer was able to give up
ownership, for instance if it was an auto_ptr. This was my point
with the extended holder interface, an auto_ptr holder can give up the
ownership and thus allowing adopt() to be used when converting to a
raw pointer.

Other shared_ptr style smart pointers might also be able to give up
shared ownership, even if boost::shared_ptr can't.

> > 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()..
>
>I think it might be simpler just to use an auto_ptr holder as the
>default mechanism.

Yeah it's simpler, but I'm not convinced that it's flexible enough.

---
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