Topic: Adding std::hash<std::tuple<...>> as a hash-combiner?
Author: Marc Mutz <marc.mutz@kdab.com>
Date: Mon, 15 May 2017 11:51:31 +0200
Raw View
Hi,
While adding std::hash specialisations for Qt types, I ran into the (probably
well-known) problem that the library does not lend a particularly helping hand
for implementing your own. In particular, there's little-to-no support to hash
memory regions and to combine hash values.
The addition of a hash specialisation for std::string_view solves the first
problem, because I can now hash contiguous memory without a memory allocation.
To solve the second problem, I was thinking of using std::tie and hash the
tuple, but to my surprise, the standard does not provide a hash specialisation
for std::tuple.
I have two questions:
1. Why is that (the std doesn't provide hash specialisations for all of its
own types)?
2. Would it be acceptable to add a specialisation for std::tuple, so users
could use std::tie as a way to combine hash values?
I get that hashing is an open problem, and a can of worms. But I am left to
wonder why the third issue of modern C++ still appears to have no solution for
hash combining (and am skeptical whether hashing std::string_views is really
the intended way to hash raw memory).
Thanks,
Marc
--
Marc Mutz <marc.mutz@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/201705151151.31806.marc.mutz%40kdab.com.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 16 May 2017 00:04:05 +0200
Raw View
This is a multi-part message in MIME format.
--------------3E9BE1B70D4DEF4CAF3A08F4
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 15/05/2017 =C3=A0 11:51, Marc Mutz a =C3=A9crit :
> Hi,
>
> While adding std::hash specialisations for Qt types, I ran into the (prob=
ably
> well-known) problem that the library does not lend a particularly helping=
hand
> for implementing your own. In particular, there's little-to-no support to=
hash
> memory regions and to combine hash values.
See
P0029R0=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0029r0.html>=20
A Unified Proposal for Composable Hashing
> The addition of a hash specialisation for std::string_view solves the fir=
st
> problem, because I can now hash contiguous memory without a memory alloca=
tion.
>
> To solve the second problem, I was thinking of using std::tie and hash th=
e
> tuple, but to my surprise, the standard does not provide a hash specialis=
ation
> for std::tuple.
>
> I have two questions:
>
> 1. Why is that (the std doesn't provide hash specialisations for all of i=
ts
> own types)?
product_type::hash function is missing in p0327r1 pending on p0029r0.=20
I'll add it.
> 2. Would it be acceptable to add a specialisation for std::tuple, so user=
s
> could use std::tie as a way to combine hash values?
I believe so.
> I get that hashing is an open problem, and a can of worms. But I am left =
to
> wonder why the third issue of modern C++ still appears to have no solutio=
n for
> hash combining (and am skeptical whether hashing std::string_views is rea=
lly
> the intended way to hash raw memory).
>
Vicente
--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/fdd10dbc-2f8c-8f37-908b-6268f4e5725d%40wanadoo.f=
r.
--------------3E9BE1B70D4DEF4CAF3A08F4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 15/05/2017 =C3=A0 11:51, Marc Mutz a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote cite=3D"mid:201705151151.31806.marc.mutz@kdab.com"
type=3D"cite">
<pre wrap=3D"">Hi,
While adding std::hash specialisations for Qt types, I ran into the (probab=
ly=20
well-known) problem that the library does not lend a particularly helping h=
and=20
for implementing your own. In particular, there's little-to-no support to h=
ash=20
memory regions and to combine hash values.
</pre>
</blockquote>
See
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8=
">
<table border=3D"1">
<tbody>
<tr>
<td><a
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0029r0.htm=
l">P0029R0</a>
</td>
<td> A Unified Proposal for Composable Hashing </td>
</tr>
</tbody>
</table>
<blockquote cite=3D"mid:201705151151.31806.marc.mutz@kdab.com"
type=3D"cite">
<pre wrap=3D"">
The addition of a hash specialisation for std::string_view solves the first=
=20
problem, because I can now hash contiguous memory without a memory allocati=
on.
To solve the second problem, I was thinking of using std::tie and hash the=
=20
tuple, but to my surprise, the standard does not provide a hash specialisat=
ion=20
for std::tuple.
I have two questions:
1. Why is that (the std doesn't provide hash specialisations for all of its
own types)?</pre>
</blockquote>
product_type::hash function is missing in p0327r1 pending on
p0029r0. I'll add it.<br>
<blockquote cite=3D"mid:201705151151.31806.marc.mutz@kdab.com"
type=3D"cite">
<pre wrap=3D"">
2. Would it be acceptable to add a specialisation for std::tuple, so users
could use std::tie as a way to combine hash values?
</pre>
</blockquote>
I believe so.<br>
<blockquote cite=3D"mid:201705151151.31806.marc.mutz@kdab.com"
type=3D"cite">
<pre wrap=3D"">
I get that hashing is an open problem, and a can of worms. But I am left to=
=20
wonder why the third issue of modern C++ still appears to have no solution =
for=20
hash combining (and am skeptical whether hashing std::string_views is reall=
y=20
the intended way to hash raw memory).
</pre>
</blockquote>
Vicente
<blockquote cite=3D"mid:201705151151.31806.marc.mutz@kdab.com"
type=3D"cite">
</blockquote>
<p><br>
</p>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fdd10dbc-2f8c-8f37-908b-6268f4e5725d%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fdd10dbc-2f8c-8f37-908b-6268f4e5725d=
%40wanadoo.fr</a>.<br />
--------------3E9BE1B70D4DEF4CAF3A08F4--
.