Boost logo

Boost :

From: Larry Evans (jcampbell3_at_[hidden])
Date: 2002-01-20 09:12:14


Peter Dimov wrote:

> From: "Larry Evans" <jcampbell3_at_[hidden]>
> > Thomas Maeder wrote:
> >
> > > Am 2002.01.19 14:23 schrieb(en) David Abrahams:
> > > >
> > > > ...which is the reason it might be better if they didn't implicitly
> > > > convert, unless Peter's precautions are taken.
> > >
> > > Are there equivalent precautions against
> > >
> > > shared_ptr<Base> b(new Derived);
> > >
> > > ?
> > >
> >
> > The following test driver snippet:
>
> [...]
>
> > where "struct subjAB :public A,public B{...}", when compiled and run with
> > "gcc version 3.1 20011207 (experimental)", fails to delete a_make.
> >
> > I am using Peter's
> http://groups.yahoo.com/group/boost/files/smart_ptr_3.zip.
>
> True, there is no way to detect the general case where a shared_ptr is being
> constructed from a T * that actually points to something derived from T.
>
> Easy cases like the above example can be detected (QoI) but in general, it

QoI =? Quality of Implementation, e.g. code reviews?

>
> is a precondition of the shared_ptr(T * p) constructor that "delete p" will
> work, and it is the user's responsibility to meet that precondition.

what about "forcing" the precondition with something like the prox_make<T>
in the code in the *prox.cpp test driver in the code uploaded at:
   http://groups.yahoo.com/group/boost/files/2001/GarbageCollectByTmplSpecializa/prox_mi.zip
The extra trouble might save some code review time.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk