On Dec 7, 2005, at 10:01 AM, Yuval Ronen wrote:
Hi. There's a shared_ptr constructor that accepts an auto_ptr<Y>&. Shouldn't it accept auto_ptr<Y> by value rather by non-const reference? It seems to me that the reference does not add anything, but only causes a VC warning (level 4):
--- warning C4239: nonstandard extension used : 'argument' : conversion from 'std::auto_ptr<_Ty>' to 'std::auto_ptr<_Ty> &' A reference that is not to 'const' cannot be bound to a non-lvalue ---
when calling this constructor with a temporary auto_ptr. This warning is a good thing and I don't want to disable it.
This shared_ptr ctor is designed such that if it throws, the auto_ptr arg retains ownership of the pointer. To transfer ownership from an rvalue auto_ptr you could: shared_ptr<Y> sp(get_auto_ptr().release()); The semantics of this latter statement are different than the ctor your pointed out only under exceptional conditions. Now if the shared_ptr ctor throws, the pointer is deleted instead of being retained by the auto_ptr. By having these two options, shared_ptr allows the client to choose which semantics work best in any given situation. <musing> A future shared_ptr might: shared_ptr(auto_ptr<T>&&); // or move_ptr This would allow lvalues or rvalues to bind, and retain the same semantics as we have today for lvalue auto_ptr's. This is just off the cuff, food for thought... </musing> -Howard