On 06/29/2016 01:42 PM, Adam C. Emerson wrote:
On 28/06/2016, Radoslaw Zarzynski wrote:
[snip]
The owning semantic has been taken from std::unique_ptr.
[snip]
Since moving or copying the static_ptr is the same as moving or
copying the stored object, I think that should be the guideline.
The least surprising way to implement things would be:
(1) static_ptr<T> is copyable if T is copyable. It is movable if T is
movable. It is nothrow-copyable if T is nothrow-copyable. It is
nothrow-movable if T is nothrow-movable.
(2) If S is derived from T, but T is copyable and S is not, attempts
to store S in static_ptr<T> should fail. Same for move. If T is
nothrow-copyable or nothrow-movable and S is not, storing S in T
should fail.
That way code written using static_ptr<T> won't have its expectations
or exception safety change out from under it.
Agreed for the most part. But as a smart pointer, there's the added
distinction of empty/not-empty.
Moves should be supported if T is movable -or- copyable (i.e. move
operations are deleted), and should result in the source being empty
regardless of whether T is moved or copied.
There's also some ambiguity with respect to construction vs. assignment.
If the destination is empty, then a move-assignment would instead result
in a move-construct of T. The same goes for copy-assignment. This means
that the noexcept specifiers will need to require both
nothrow-constructible and nothrow-assignable.
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
