Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-01-20 09:20:05


From: "Larry Evans" <jcampbell3_at_[hidden]>
> Peter Dimov wrote:
>
> > 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?

QoI = Quality of Implementation issue, i.e. something that is not enforced
in the standard but may be delivered by implementations; for example, adding
a

template<class Y> shared_ptr(Y * p);

constructor to shared_ptr that tries to detect this kind of error.

> > 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/GarbageCollectByTmplSpecializ
a/prox_mi.zip
> The extra trouble might save some code review time.

Yes; my point was that in general, construction from raw pointer is
inherently unsafe, and the user needs to take precautions.

If we remove the raw pointer constructor and instead offer a family of

shared_ptr<T> create(<args>)
{
    return shared_ptr<T>(new T(<args>));
}

functions, this particular problem will disappear.

--
Peter Dimov
Multi Media Ltd.

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