Re: Does std::unique_ptr support self-reset?
Am 12.08.2013 19:48, schrieb Greg Marr:
On Monday, August 12, 2013 10:23:38 AM UTC-4, SG wrote:
Actually, this looks good to me. It does not support self-reset but it
does not have to according to the standard. What do you think is
non-conforming about it?
It does support self-reset, exactly as does the MSVC implementation
that Daniel Krugler said is non-conforming, because it doesn't
call get_deleter()(old_value) if the old value and the new value
are the same.
I'm confused by your statement here: *If* the argument of reset() is the
owned pointer itself, the effects will be a double-delete: The first one
within reset and the second one in the first of another reset or the
destructor of std::unique_ptr.
This is different than the reset() later in the same file, which is
void
reset(pointer __p = pointer()) noexcept
{
using std::swap;
swap(std::get<0>(_M_t), __p);
if (__p != nullptr)
get_deleter()(__p);
}
I'm confused a second time: Sebastian Gesemann was referring to exactly
this version of reset as I understand his response.
The difference is
if (__p != nullptr)
vs
if (__p != pointer())
This is not a semantics difference, because as of the NullablePointer
requirements imposed on type 'pointer' we can build the following logic
chain:
a) __p is a value of (possibly const) 'pointer' and nullptr is a
(possibly const) value of type std::nullptr_t, according to Table 25 ?
NullablePointer requirements [nullablepointer]
__p != nullptr
has the semantics of
!(__p == nullptr)
and the sub-expression
__p == nullptr
has the semantics of
__p == pointer()
b) Using the same starting point we note that
__p != pointer()
has the semantics of
!(__p == pointer())
and we end up with the same essential effects as in (a).
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]