[Bug libstdc++/54351] ~unique_ptr() should not set __p to null
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-22 18:43:47 UTC --- Hmm, the behaviour was probalby correct prior to fixing PR 43183, as the old implementation of reset() did exactly what is required of the destructor. However, the lifetime of the unique_ptr ends when the destructor starts ([basic.life]/1) so I don't believe it is legitimate to access it at that point.
[Bug libstdc++/54351] ~unique_ptr() should not set __p to null
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-22 18:47:07 UTC --- That said, whether the testcase is valid or not, I don't see any harm in making the change.
[Bug libstdc++/54351] ~unique_ptr() should not set __p to null
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-22 Ever Confirmed|0 |1 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-22 18:51:27 UTC --- Looking more closely, [basic.life]/5 and [class.cdtor]/1 do seem to allow your testcase. So confirmed.
[Bug libstdc++/54351] ~unique_ptr() should not set __p to null
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-22
18:58:22 UTC ---
I'll test this change:
@@ -169,7 +169,13 @@
#endif
// Destructor.
- ~unique_ptr() noexcept { reset(); }
+ ~unique_ptr() noexcept
+ {
+ auto __ptr = std::get0(_M_t);
+ if (__ptr != pointer())
+ get_deleter()(__ptr);
+ __ptr = pointer();
+ }
// Assignment.
unique_ptr
[Bug libstdc++/54351] ~unique_ptr() should not set __p to null
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351 --- Comment #5 from Geoff Romer gromer at google dot com 2012-08-22 19:11:17 UTC --- Don't forget the array specialization. Doesn't the first line of your new destructor shadow the __p member with a __p local variable? Why is that line needed at all?
[Bug libstdc++/54351] ~unique_ptr() should not set __p to null
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-22 19:28:15 UTC --- (In reply to comment #5) Don't forget the array specialization. I won't :-) Doesn't the first line of your new destructor shadow the __p member with a __p local variable? Why is that line needed at all? There is no __p member.
