From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-08-29 21:11:19


From: Valentin Bonnard <Bonnard.V_at_[hidden]>
> Greg Colvin wrote:
> >
> > From: Valentin Bonnard <Bonnard.V_at_[hidden]>
> > > Thomas Matelich wrote:
> > >
> > > > <whine> I wanna inherit shared_ptr </whine>
> > > >
> > > > Anyway, here's my situation, I'm writing a library for a simple plugin
> > > > architecture. Objects can be created from classes in dynamic libraries
> > > > dynamically. I want those objects to be shared_ptrs and be able to
> > > > construct themselves.
> > >
> > > I don't understand.
> > >
> > > > I think this qualifies as an isa relationship.
> > > > In general, their only purpose is to be used like a shared_ptr.
> > > >
> > > > So, is shared_ptr always going to use private for share and have no
> > > > virtual destructor,
> > >
> > > Please explain why you think it should expose its implementation
> > > details and why it should have a virtual destructor.
> > >
> > > > or is this matter up for discussion?
> > >
> > > We can discuss it, but I think I know the outcome.
> >
> > I wouldn't be so sure.
> >
> > We've been considering an improvement to shared_ptr to
> > add template constructors parameterized on a function
> > or functor that does the deletion.
>
> I have proposed some generalisations on std::auto_ptr
> and boost::*_ptr, and the answer has always been: keep
> it simple.

Yes. It's a struggle to get the simplest possible class
that provides the functionality people need. But I remain
happy to accept your dynamic cast patches.

> > We can arrange it
> > so that type of shared_ptr(T*) is the same as the type
> > of shared_ptr(T*,deleter),
>
> Defaulted template parameter class Desallocator=boost::Delete ?

Something like that. I want to be able to accept either
a function or a functor with no space overhead by default.

> Inherit shared_ptr<T*> from generalised_shared_ptr<T*, Delete> ?

Probably not.

> > which might provide for the sort of polymorphism Thomas wants.
>
> I still don't understand.

I need to write it up, but the idea is that you can pass
around shared_ptr<T> without needing to know how the object
pointed to by the raw pointer was allocated of how it will be
deleted.