From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) by sourceware.org (Postfix) with ESMTPS id 23FB53854835; Mon, 24 May 2021 09:31:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 23FB53854835 Received: by mail-wr1-x430.google.com with SMTP id v12so27796668wrq.6; Mon, 24 May 2021 02:31:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=/plg34yOrOLYamaY/1wwlCcKJqcEa/npUZ5COqwJ6FI=; b=pEDlr8i9b0ygTLhZWTaq+UytjzzKQw+iduHFUZRn9nEADco+06FKZQvfxuMhgXFwiG JXQgxzSOz3del5mD+T2nMhqsoAhHF24eOn5LatfxD/z/iwDROa/lHbAzb15/zAQQIZRV 3hcjELOum1WDb3miTaD5emnw4XNlVoGw2Y5oyenHT85H+po1CWuf0WSgWLIaxw+aNde+ 0bgbesjzZrjweJl6GET7LskatEN6GBiQL2cjuKhAi6YpMwGN5yEPhGvA0hR/wWx9sW6F OON5Sp1gatVnq8GPkUbi/TrV/E5/d1bLGQClvMTNWEaI0OSQkiQooSEDLe1ZQTRsAs0n XB1g== X-Gm-Message-State: AOAM5337nr6OMfUho/I2hUlAGa0Lg78Cv3BFTN3f4uWoVuKrX7k8XDdJ o/2Dlyo/Lso58Vmbmn4VSbe1uP1esD4= X-Google-Smtp-Source: ABdhPJypzHp63RorcxMuhXvNu4+arxb4Nv2f+0pJiH6FgRhos7bL2AcUZ3byrlwOT75uojcpGCMu6Q== X-Received: by 2002:a5d:690b:: with SMTP id t11mr18494244wru.250.1621848716925; Mon, 24 May 2021 02:31:56 -0700 (PDT) Received: from [192.168.1.75] (38.200.13.93.rev.sfr.net. [93.13.200.38]) by smtp.googlemail.com with ESMTPSA id g10sm11673317wrq.12.2021.05.24.02.31.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 May 2021 02:31:55 -0700 (PDT) Subject: Re: [PATCH] Hashtable PR96088 To: Jonathan Wakely Cc: "libstdc++@gcc.gnu.org" , gcc-patches References: <5b198dd5-cb89-91a0-9070-13927ac263a4@gmail.com> <524e2eee-a4ee-a05e-087f-6000c8274eff@gmail.com> <21854fd0-ad6b-1eaa-adaa-2074421fc107@gmail.com> <7bd748f6-77bd-fdcc-f925-1700ac9da3de@gmail.com> From: =?UTF-8?Q?Fran=c3=a7ois_Dumont?= Message-ID: <74d39bb0-6c12-1c6b-7444-08f263252865@gmail.com> Date: Mon, 24 May 2021 11:31:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: fr X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2021 09:31:59 -0000 On 20/05/21 6:44 pm, Jonathan Wakely wrote: > On 06/05/21 22:03 +0200, François Dumont via Libstdc++ wrote: >> Hi >> >>     Considering your feedback on backtrace in debug mode is going to >> take me some time so here is another one. >> >>     Compared to latest submission I've added a _Hash_arg_t partial >> specialization for std::hash<>. It is not strictly necessary for the >> moment but when we will eventually remove its nested argument_type it >> will be. I also wonder if it is not easier to handle for the >> compiler, not sure about that thought. > > The std::hash specializations in libstdc++ define argument_type, but > I'm already working on one that doesn't (forstd::stacktrace). > > And std::hash can be specialized by users, > and is not required to provide argument_type. > > So it's already not valid to assume that std::hash::argument_type > exists. > >> @@ -850,9 +852,56 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION >>     iterator >>     _M_emplace(const_iterator, false_type __uks, _Args&&... __args); >> >> +      template >> +    std::pair >> +    _M_insert_unique(_Kt&&, _Arg&&, const _NodeGenerator&); >> + >> +      // Detect nested argument_type. >> +      template> >> +    struct _Hash_arg_t >> +    { typedef _Kt argument_type; }; >> + >> +      // std::hash >> +      template >> +    struct _Hash_arg_t<_Kt, std::hash<_Arg>> >> +    { typedef _Arg argument_type; }; >> + >> +      // Nested argument_type. >> +      template >> +    struct _Hash_arg_t<_Kt, _Ht, >> +              __void_t> >> +    { typedef typename _Ht::argument_type argument_type; }; >> + >> +      // Function pointer. >> +      template >> +    struct _Hash_arg_t<_Kt, std::size_t(*)(const _Arg&)> >> +    { typedef _Arg argument_type; }; >> + >> +      template> +           typename _ArgType >> +         = typename _Hash_arg_t<_Kt, _Hash>::argument_type> >> +    static typename conditional< >> +      __is_nothrow_convertible<_Kt, _ArgType>::value, _Kt&&, >> key_type>::type > > Please use __conditional_t<...> here instead of > typename conditional<...>::type. I forgot to say in my new proposal that I didn't find the __conditional_t. I can see a std::condition_t but only in C++14. Do you want to add a __conditional_t for C++11 ?