From: Howard Hinnant (hinnant_at_[hidden])
Date: 2002-09-21 16:25:48
On Saturday, September 21, 2002, at 12:06 PM, Peter Dimov wrote:
> A swap-capable scoped_ptr is the best solution. [for implementing
I agree in the context of the current language.
If move_ptr comes to be, I think move_ptr might be a better solution.
Rationale: scoped_ptr::swap is just another name for move assignment
on scoped_ptr. It transfers resources. In the context of move
semantics, it seems odd that a class does not have move semantics
(especially move assignment) yet supports a resource transferring swap.
If a handle/body used move_ptr as an implementation, the handle copy
constructor and copy assignment would be implemented in the same
fashion as with scoped_ptr. And the compiler generated versions would
compile-time like scoped_ptr. (the move_ptr in the proposal is
currently lacking a swap function, but that is of course easily
What if the handle/body wanted to implement move semantics? It might
impl_ = static_cast<Ptr&&>(h.impl_);
(Ptr is a typedef for the move_ptr)
With scoped_ptr the move constructor is still doable, but perhaps not
as intuitive (but that's a judgment call). You have to take advantage
of the fact that the only way to transfer scoped_ptr's resource is via
swap. That is, you need to default construct the target scoped_ptr
first, and then swap with the source:
And move assignment can also be accomplished with swap.
I find myself wondering what is the niche that scoped_ptr fills better
than move_ptr. And my best guess right now is the role of a local auto
variable where the resource never needs to be transferred out of the
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk