Boost logo

Boost :

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-08-22 09:25:46


----- Original Message -----
From: "Milutin Jovanovic" <miki_at_[hidden]>

> From: "David Abrahams" <abrahams_at_[hidden]>
> > 1. noncopyable can be used when no sensible copy semantics exist. There
is
> > simply no analogue for dynamic construction. If it makes sense to write
> > X x;
> > then it also makes sense to say
> > std::auto_ptr<X> x(new X);
>
> Until recently I did not see much use for it, but we have a concrete
example
> in our thread conversations. The mutex_lock class that locks a mutex only
> within a scope should not be allowed to exist on heap and that way keep
the
> lock outside of scopes.

I disagree. It makes perfect sense to me to pass a mutex lock to a function
by auto_ptr, where it is the receiving function's responsibility to release
the lock when it is "done" with the resource. The auto_ptr guarantees that
it will be released on exit if there is no explicit release.

What I'm trying to say is that noncopyable prevents copying when there are
actually no legitimate copy semantics, but I think there are always
legitimate reasons to dynamically allocate an object.

Maybe I'm mistaken, but it seems to me that most people don't go about
dynamically allocating things willy-nilly where stack allocation would do.
Is this a likely enough sort of abuse to make it worth preventing the
legitimate uses?

-Dave


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