[Bug libstdc++/38265] STL treats explicit constructors as converting constructors

2015-05-19 Thread gromer at google dot com
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

[Bug libstdc++/58159] unique_ptr::reset should have debug assertion for self-reset

2014-09-17 Thread gromer at google dot com
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

[Bug libstdc++/60970] New: Support std::hash with enum types (LWG 2148)

2014-04-25 Thread gromer at google dot com
: 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).

[Bug preprocessor/20262] __LINE__ implementation flaky.

2013-12-16 Thread gromer at google dot com
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

[Bug libstdc++/58159] New: unique_ptr::reset should have debug assertion for self-reset

2013-08-14 Thread gromer at google dot com
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

[Bug libstdc++/58159] unique_ptr::reset should have debug assertion for self-reset

2013-08-14 Thread gromer at google dot com
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

[Bug libstdc++/58159] unique_ptr::reset should have debug assertion for self-reset

2013-08-14 Thread gromer at google dot com
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

[Bug libstdc++/54351] ~unique_ptr() should not set stored pointer to null

2012-12-18 Thread gromer at google dot com
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

[Bug libstdc++/54351] New: ~unique_ptr() should not set __p to null

2012-08-22 Thread gromer at google dot com
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

[Bug libstdc++/54351] ~unique_ptr() should not set __p to null

2012-08-22 Thread gromer at google dot com
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

[Bug libstdc++/54351] ~unique_ptr() should not set stored pointer to null

2012-08-22 Thread gromer at google dot com
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