From: Howard Hinnant (hinnant_at_[hidden])
Date: 2002-09-30 15:46:12
On Monday, September 30, 2002, at 02:47 PM, Ed Brey wrote:
> That is not to say that we cannot qualifiy scoped_ptr at all. Its
> transfer semantics are limited to "transfer in", which differentiates
> it greatly from auto_ptr. I submit that this by far the less
> dangerous of the two directions, and so need not concern us greatly.
Agreed, as long as it is safe to transfer out of the source, and it is
clear that a transfer is taking place.
> To me the question is, given that we have to live with transfer in,
> how do we define its details? My answer would be to allow anything
> tends not to be error prone. Clearly, we don't allow operator=(T*).
> IMHO, given the semantics and purpose of auto_ptr, an overload for it
> is OK. By using auto_ptr in the first place, the user has already
> jumped into move-via-copy-syntax land, because such is the nature of
> auto_ptr, and scoped_ptr's job is not to change auto_ptr's nature. (A
> viable alternative is the view that auto_ptr only applies
> move-via-copy-syntax when used with itself, in which case no other
> class should interoprate with it.)
This is all certainly ok. I guess I've just grown leery of auto_ptr
(after being a big fan of it) and have started to shun
move-via-copy-syntax. Maybe it is just a phase I'm going through. ;-)
I'm also gun shy of adding more capability to scoped_ptr. auto_ptr
started out simple too but grew to meet more and more demands. At some
point you've got to say: stop, that functionality belongs in a
separate class. Not saying we've crossed that line with scoped_ptr or
auto_ptr. Just saying that line is out there somewhere, and we should
be careful of crossing it. Maybe just discussing the existence of such
a boundary is sufficient for now.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk