220 21305 article Path: news.gmane.org!not-for-mail From: Shahms King Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: missing hash_code result in P0029 Date: Mon, 05 Oct 2015 17:34:04 +0000 Lines: 269 Approved: news@gmane.org Message-ID: References: <1572715.jJmjmrJA0J@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114363ac08412c05215eec98 X-Trace: ger.gmane.org 1444066475 29974 80.91.229.3 (5 Oct 2015 17:34:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 5 Oct 2015 17:34:35 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC7ML3M6QIDBBFXJZKYAKGQE7MHAYAY@isocpp.org Mon Oct 05 19:34:19 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yk0-f199.google.com ([209.85.160.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zj9eS-0003Hy-Lz for gclcip-std-proposals@m.gmane.org; Mon, 05 Oct 2015 19:34:16 +0200 Original-Received: by ykdz138 with SMTP id z138sf250848721ykd.3 for ; Mon, 05 Oct 2015 10:34:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=Qz2cXttKxgnHDb+cnxOqGqlV1LuAPJHJ4b2zpEYbs4k=; b=BwBJDY1zgcOuhq9/3LLkZT2W76iJm3WYhdJMu6sTk2w8B15RyVebVzWTdkeh/6BkaS RY8uyCaEef7+BcUpPJAKW7KeT8d+xeBpGMfuFCt1lo+5+/SauHYgpQmfQtOAnQ+cJZzY FFp2UM9InyfrcsNrUrTZJ9cZ2inkWKHRRX9sEPx3RVdtM/7OjClQX9407oIhnFvmqNcu vChjQaCratVYCKlCishhSoCC/zgspF8bebJVMzmyaKVY+Z7P6dvQubRk9Iv4YlDrg7yP 6s/7vnv6aIYjSj8mCf+HYAlZ5ruIxZ08WDl1QvnhSYEZtjWktc/5l+ZHODThOYDPHMkw kh+A== X-Gm-Message-State: ALoCoQkFVES348rmvuwAEgdx7WcFILXv2p7qAqTgv73HJJdqj0rrey9bxhNMTzIRU2LyFSLTCmbj X-Received: by 10.129.4.15 with SMTP id 15mr26172018ywe.54.1444066455890; Mon, 05 Oct 2015 10:34:15 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.36.148 with SMTP id p20ls3103335qgp.46.gmail; Mon, 05 Oct 2015 10:34:14 -0700 (PDT) X-Received: by 10.31.168.79 with SMTP id r76mr1429030vke.102.1444066454417; Mon, 05 Oct 2015 10:34:14 -0700 (PDT) Original-Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com. [2607:f8b0:400c:c05::233]) by mx.google.com with ESMTPS id j68si14517676vke.60.2015.10.05.10.34.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Oct 2015 10:34:14 -0700 (PDT) Received-SPF: pass (google.com: domain of shahms.king@gmail.com designates 2607:f8b0:400c:c05::233 as permitted sender) client-ip=2607:f8b0:400c:c05::233; Original-Received: by vkao3 with SMTP id o3so101115639vka.2 for ; Mon, 05 Oct 2015 10:34:14 -0700 (PDT) X-Received: by 10.31.16.11 with SMTP id g11mr20619878vki.152.1444066454157; Mon, 05 Oct 2015 10:34:14 -0700 (PDT) In-Reply-To: <1572715.jJmjmrJA0J@tjmaciei-mobl4> X-Original-Sender: shahms.king@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of shahms.king@gmail.com designates 2607:f8b0:400c:c05::233 as permitted sender) smtp.mailfrom=shahms.king@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:21305 Archived-At: --001a114363ac08412c05215eec98 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 5, 2015 at 10:07 AM Thiago Macieira wrote: > On Monday 05 October 2015 09:17:45 'Geoffrey Romer' via ISO C++ Standard - > Future Proposals wrote: > > The API for extracting a hash value, and symmetrically the API for > > initializing the HashCode, is deliberately left unspecified. > > So if I want to write a new portable container that relies on hashing, I > can't? What's the rationale for that? > The proposal doesn't change the requirements on the hash-function callable itself. If you want to implement a portable container that relies on hashing, you have a template parameter for the hash function which adheres to the same interface as std::hash. It is callable with the element type and returns a size_t. ~/.ssh/id_rsa_github > > > In the case of > > std::hash_code it doesn't matter, because only std::hash needs to be > aware > > of those details. > > Most definitely not. I started with an example that disagrees with this > perspective. > > > Other HashCode types can provide similar functor > > wrappers, or explicitly specify those APIs however they choose. > > So if I write my own element type T, I need to specify its hashing function > for std::unordered_map and SomeOtherHash? > If you write your own element type T, you need to implement one of: std::hash_code hash_value(std::hash_code, T); Or (preferred, to support a variety of algorithms): template H hash_value(H, T); > > The initialization API is unspecified because it depends on the > > implementation details of the HashCode (e.g. hashing::farmhash needs a > > pointer to its state as an input). The value-extraction API is > unspecified > > because it's unsafe: in many cases it will leave the HashCode in an > > unusable state. I solved that in the prototype by making it rvalue-ref > > qualified, but then I realized there's no need to specify it at all > > (particularly when the initialization API is also unspecified), and an > > unspecified API is simpler, safer, and harder to bikeshed. > > > > I had thought I spelled this out in the paper somewhere, but I can't > > immediately find it, so that may be an oversight on my part. > > I find that those reasons invalidate the proposal. > > If I can't use them in my own hashing container, they're unusable. > You can trivially use them in your own hashing container, as you would now. The primary thing that is being changed is the mechanism by which user-defined types can supply their data to the hash function, not the interface for retrieving final values from that hash function. The high-level API for retrieving a hash value from an object is unchanged, e.g. template struct hash { size_t operator() (const T& value) const { std::hash_code state = __implementation_defined_init(); state = hash_value(state, value); return __implementation_defined_extract_value(state); } }; Or: struct MyHashCode { ... private: ... friend class MyHash; operator size_t() const; }; struct MyHash { template size_t operator()(const T& value) const { MyHashCode state; return hash_value(state, t); } }; Essentially, the only part which remains undefined is the internal interface between the top-level hash algorithm and its internal state. --Shahms > > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org > Software Architect - Intel Open Source Technology Center > PGP/GPG: 0x6EF45358; fingerprint: > E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 > > -- > > --- > You received this message because you are subscribed to the Google Groups > "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to std-proposals+unsubscribe@isocpp.org. > To post to this group, send email to std-proposals@isocpp.org. > Visit this group at > http://groups.google.com/a/isocpp.org/group/std-proposals/. > -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. --001a114363ac08412c05215eec98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 5,= 2015 at 10:07 AM Thiago Macieira <thiago@macieira.org> wrote:
~/.ssh/id_rsa_github
=C2=A0=

> In the case of
> std::hash_code it doesn't matter, because only std::hash needs to = be aware
> of those details.

Most definitely not. I started with an example that disagrees with this
perspective.

> Other HashCode types can provide similar functor
> wrappers, or explicitly specify those APIs however they choose.

So if I write my own element type T, I need to specify its hashing function=
for std::unordered_map and SomeOtherHash?

If you write your own element type T, you need to implement one of:

std::hash_code hash_value(std::hash_code, T);

Or (preferred, to support a variety of algorithms):
<= div>
template <typename H>
H hash_value(H, T)= ;


> The initialization API is unspecified because it depends on the
> implementation details of the HashCode (e.g. hashing::farmhash needs a=
> pointer to its state as an input). The value-extraction API is unspeci= fied
> because it's unsafe: in many cases it will leave the HashCode in a= n
> unusable state. I solved that in the prototype by making it rvalue-ref=
> qualified, but then I realized there's no need to specify it at al= l
> (particularly when the initialization API is also unspecified), and an=
> unspecified API is simpler, safer, and harder to bikeshed.
>
> I had thought I spelled this out in the paper somewhere, but I can'= ;t
> immediately find it, so that may be an oversight on my part.

I find that those reasons invalidate the proposal.

If I can't use them in my own hashing container, they're unusable.<= br>

You can trivially use them in your own = hashing container, as you would now.=C2=A0 The primary thing that is being = changed is the mechanism by which user-defined types can supply their data = to the hash function, not the interface for retrieving final values from th= at hash function.=C2=A0 The high-level API for retrieving a hash value from= an object is unchanged, e.g.

template <typenam= e T>
struct hash {
=C2=A0 size_t operator() (const T= & value) const {
=C2=A0 =C2=A0 std::hash_code state =3D __imp= lementation_defined_init();
=C2=A0 =C2=A0 state =3D hash_value(st= ate, value);
=C2=A0 =C2=A0 return __implementation_defined_extrac= t_value(state);
=C2=A0 }
};

Or= :

struct MyHashCode {
=C2=A0 ...
=C2=A0private:
=C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 f= riend class MyHash;
=C2=A0 =C2=A0 operator size_t() const;
<= div>};

struct MyHash {
=C2=A0 template &= lt;typename T>
=C2=A0 size_t operator()(const T& value) co= nst {
=C2=A0 =C2=A0 MyHashCode state;
=C2=A0 =C2=A0 ret= urn hash_value(state, t);
=C2=A0 }
};

Essentially, the only part which remains undefined is the internal = interface between the top-level hash algorithm and its internal state.

--Shahms
=C2=A0

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535= 8

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.c= om/a/isocpp.org/group/std-proposals/.

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--001a114363ac08412c05215eec98-- .