https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265
Geoff Romer gromer at google dot com changed:
What|Removed |Added
CC||gromer at google
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58159
--- Comment #6 from Geoff Romer gromer at google dot com ---
A Chromium maintainer privately pointed out a use case that would be thwarted
by a check like this: basically, unique_ptr is used to hold pointers from a
legacy API, using a custom
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gromer at google dot com
std::hashT appears to be undefined when T is an enum type, contrary to the
resolution of LWG 2148
(http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2148).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20262
Geoff Romer gromer at google dot com changed:
What|Removed |Added
CC||gromer at google
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gromer at google dot com
unique_ptr::reset() should have a debug assertion for the case that the input
pointer is not null, and is equal to the pointer already stored. This is
virtually
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58159
Geoff Romer gromer at google dot com changed:
What|Removed |Added
CC||gromer at google
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58159
--- Comment #3 from Geoff Romer gromer at google dot com ---
What's the standard of review here? If we can only assert on undefined
behavior, even in debug mode, then this just can't be done (although maybe we
should make this undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351
--- Comment #11 from Geoff Romer gromer at google dot com 2012-12-18 21:59:23
UTC ---
From discussion on the C++ LWG reflector, it appears that the standard's
requirements on library types are intended to apply only during their lifetime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351
Bug #: 54351
Summary: ~unique_ptr() should not set __p to null
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351
--- Comment #7 from Geoff Romer gromer at google dot com 2012-08-22 19:49:28
UTC ---
(In reply to comment #6)
(In reply to comment #5)
Don't forget the array specialization.
I won't :-)
Doesn't the first line of your new destructor
11 matches
Mail list logo