On 20/01/17 17:50 +0200, Ville Voutilainen wrote:
On 20 January 2017 at 17:27, Ville Voutilainen
wrote:
On 20 January 2017 at 17:21, Jonathan Wakely wrote:
This part for std::unique_ptr is the only part that isn't C++17-only,
so this is the part I'm most nervous about. Given that we're in sta
On 20 January 2017 at 17:27, Ville Voutilainen
wrote:
> On 20 January 2017 at 17:21, Jonathan Wakely wrote:
>> This part for std::unique_ptr is the only part that isn't C++17-only,
>> so this is the part I'm most nervous about. Given that we're in stage
>> 4 and this isn't even fixing something i
On 20 January 2017 at 17:21, Jonathan Wakely wrote:
> This part for std::unique_ptr is the only part that isn't C++17-only,
> so this is the part I'm most nervous about. Given that we're in stage
> 4 and this isn't even fixing something in Bugzilla (even if it is a
> real bug), would it be possibl
On 20/01/17 17:00 +0200, Ville Voutilainen wrote:
--- a/libstdc++-v3/include/bits/unique_ptr.h
+++ b/libstdc++-v3/include/bits/unique_ptr.h
@@ -789,10 +789,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{ return !(nullptr < __x); }
/// std::hash specialization for unique_ptr.
- template
-struc
Tested on Linux-x64. The approach is a bit ugly, the hashes derive
from __poison_hash and also use its nested __enable_hash_call as
an argument for another utility base. I prototyped various approaches
to try to decrease that duplication, but didn't like any of them (more
utility bases, aliases, ev
