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.
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.
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
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
+ {
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
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
