Topic: N3573: Why heterogenous extensions to unordered
Author: jgottman6@gmail.com
Date: Mon, 8 Apr 2013 17:36:46 -0700 (PDT)
Raw View
------=_Part_5167_18593397.1365467806728
Content-Type: text/plain; charset=ISO-8859-1
N3573 suggests allowing lookup into unordered sets and maps by alternative
keys, as long as operator== can compare both types and the hashes of the
two types are compatible. The use case given is
std::unordered_map<std::string, int> map;
map.find("foo"); // We don't have to construct string("foo") to do the
find.
While this would be useful, there is too much chance of two types being
equality-comparable but having incompatible hashes. For example, under gcc
8.0,
std::hash<long>(-1L) == 18446744073709551615
and
std::hash<double>(-1.0) == 11078049357879903929
Thus, if N3573 were accepted, this code would fail:
std:unordered_set<double> s;
s.insert(-1L); // Internally converts -1L to -1.0 and hashes that
assert(s.find(-1L) != s.end()); // fails. find calls hash<long>(-1L) and
gets the wrong bucket
Note that under C++11 rules this code succeeds, because find also converts
its parameter to double before hashing.
Joe Gottman
--
---
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/?hl=en.
------=_Part_5167_18593397.1365467806728
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
N3573 suggests allowing lookup into unordered sets and maps by alternative =
keys, as long as operator=3D=3D can compare both types and the hashes of th=
e two types are compatible. The use case given is<br><br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><code=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">unordered_map</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">string</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">int</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> ma=
p</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br> map</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">find</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #080;" class=3D"styled-by-prettify">"foo"</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styl=
ed-by-prettify">// We don't have to construct string("foo") to do the find.=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
></code></div></code></div><br><br>While this would be useful, there is too=
much chance of two types being equality-comparable but having incompatible=
hashes. For example, under gcc 8.0, <div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;=
" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">hash</span><span style=3D"color: #080;" class=3D"styled-by-=
prettify"><long></span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(-</span><span style=3D"color: #066;" class=3D"styled-by-pretti=
fy">1L</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #066;" class=3D"styled-by-prettify">18446744073709551615</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code><=
/div>and<br><div class=3D"prettyprint" style=3D"background-color: rgb(250, =
250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wi=
dth: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D=
"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">=
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">hash</span><spa=
n style=3D"color: #080;" class=3D"styled-by-prettify"><double></span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(-</span><span st=
yle=3D"color: #066;" class=3D"styled-by-prettify">1.0</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">=3D=3D</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-b=
y-prettify">11078049357879903929</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br><br>Thus, if N357=
3 were accepted, this code would fail:<br><br><div class=3D"prettypri=
nt" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 1=
87, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><=
code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">unordered_set</span><span style=3D"color: #080;" cl=
ass=3D"styled-by-prettify"><double></span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> s</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>s</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>insert</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(-<=
/span><span style=3D"color: #066;" class=3D"styled-by-prettify">1L</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #800;" class=3D"styled-by-prettify">// Internally converts -1L to -1.0 a=
nd hashes that</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">as=
sert</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">s</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">find</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(-</span><span style=3D"color: #066;" c=
lass=3D"styled-by-prettify">1L</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">!=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">end</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">());</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800=
;" class=3D"styled-by-prettify">// fails. find calls hash<long>(-1L) =
and gets the wrong bucket</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span></div></code></div><br><br>Note that under C++11 =
rules this code succeeds, because find also converts its parameter to doubl=
e before hashing.<br><br>Joe Gottman<br>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_5167_18593397.1365467806728--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Tue, 9 Apr 2013 03:58:15 -0700 (PDT)
Raw View
------=_Part_2732_13076425.1365505095097
Content-Type: text/plain; charset=ISO-8859-1
Actually, I don't believe that exact use case *is* in the paper. And,
whilst it's nice, it would depend on std::hash<const char*> treating it's
argument like a C string rather than a generic pointer, and I don't know if
it does. If so, then that would certainly be a nice use case- and you could
certainly provide a custom hasher for one lookup that could perform this
using another of the features in N3573.
Whilst I admit that I overlooked implicit conversions in this case, it's
not a breaking problem, I'll just have to provide a new name, like, find_by
or some such (and the same for erasure). That also means I'd have to use
SFINAE to limit operator[] too, since that cannot be given another name, or
perhaps some kind of trait. It would have been nice to have something like
template<typename T, typename U> void find(std::unordered_set<T> t, U&& u) {
t.find(u);
}
function for any U, I doubt any such code exists, so I'm not that bothered
by losing it.
Secondly, there are a couple of other things I wanted to mention about
N3573. The proposal is based on my own experience of the limitations of
these Standard containers for move-only types, but in fact, there are a few
others I failed to address simply because I didn't come across them in my
experience. Specifically, std::map and std::set will need a similar
treatment, and secondly, I did not consider a moving erase. Currently, it
is impossible to move an element out of a
map/set/unordered_map/unordered_set, which is a bit painful IYAM- my
previous use cases simply did not require it, so I didn't consider it.
Obviously this would have to be move-out-and-erase in one step to prevent
violating the invariants of the container.
--
---
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/?hl=en.
------=_Part_2732_13076425.1365505095097
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Actually, I don't believe that exact use case *is* in the paper. And, whils=
t it's nice, it would depend on std::hash<const char*> treating it's =
argument like a C string rather than a generic pointer, and I don't know if=
it does. If so, then that would certainly be a nice use case- and you coul=
d certainly provide a custom hasher for one lookup that could perform this =
using another of the features in N3573.<div><br></div><div>Whilst I admit t=
hat I overlooked implicit conversions in this case, it's not a breaking pro=
blem, I'll just have to provide a new name, like, find_by or some such (and=
the same for erasure). That also means I'd have to use SFINAE to limit ope=
rator[] too, since that cannot be given another name, or perhaps some kind =
of trait. It would have been nice to have something like</div><div><br></di=
v><div style=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb=
(187, 187, 187); word-wrap: break-word;" class=3D"prettyprint"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
class=3D"styled-by-prettify">template</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">ty=
pename</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> U</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> find</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify">unordered_set</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> t</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> U</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&&</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> u</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br> t</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">find</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">u</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code></div=
><div><br></div><div>function for any U, I doubt any such code exists, so I=
'm not that bothered by losing it.<br></div><div><br></div><div>Secondly, t=
here are a couple of other things I wanted to mention about N3573. The prop=
osal is based on my own experience of the limitations of these Standard con=
tainers for move-only types, but in fact, there are a few others I failed t=
o address simply because I didn't come across them in my experience. Specif=
ically, std::map and std::set will need a similar treatment, and secondly, =
I did not consider a moving erase. Currently, it is impossible to move an e=
lement out of a map/set/unordered_map/unordered_set, which is a bit painful=
IYAM- my previous use cases simply did not require it, so I didn't conside=
r it. Obviously this would have to be move-out-and-erase in one step to pre=
vent violating the invariants of the container.</div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_2732_13076425.1365505095097--
.
Author: sgheeren@gmail.com
Date: Tue, 9 Apr 2013 04:38:38 -0700 (PDT)
Raw View
------=_Part_5370_27775616.1365507518614
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, April 9, 2013 12:58:15 PM UTC+2, DeadMG wrote:
>
> ... and secondly, I did not consider a moving erase. Currently, it is
> impossible to move an element out of a map/set/unordered_map/unordered_set,
> which is a bit painful IYAM- my previous use cases simply did not require
> it, so I didn't consider it. Obviously this would have to be
> move-out-and-erase in one step to prevent violating the invariants of the
> container.
Have you had look at proposal n3586 "Splicing Maps and Sets"? Seems to
address the same usecase area:
As technically a splice method is not possible for maps or sets, the goal
> is to add a new function called remove, which returns a unique pointer
> holding the node, and add a new overload to insert, allowing to insert the
> node into the new container
Seth
--
---
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/?hl=en.
------=_Part_5370_27775616.1365507518614
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tuesday, April 9, 2013 12:58:15 PM UTC+2, DeadMG wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">... and secondly, I did not consider a moving e=
rase. Currently, it is impossible to move an element out of a map/set/unord=
ered_map/unordered_set, which is a bit painful IYAM- my previous use cases =
simply did not require it, so I didn't consider it. Obviously this would ha=
ve to be move-out-and-erase in one step to prevent violating the invariants=
of the container.</blockquote><div><br></div><div>Have you had look at pro=
posal n3586 "Splicing Maps and Sets"? Seems to address the same usecase are=
a:</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">As tech=
nically a splice method is not possible for maps or sets, the goal is to ad=
d a new function called remove, which returns a unique pointer holding the =
node, and add a new overload to insert, allowing to insert the node into th=
e new container </blockquote><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"> </blockquote><div><br></div><div>Seth </div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_5370_27775616.1365507518614--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Tue, 9 Apr 2013 04:40:25 -0700 (PDT)
Raw View
------=_Part_287_11398672.1365507625493
Content-Type: text/plain; charset=ISO-8859-1
That refers to moving a node out of one set and into another, whereas I am
referring to moving the *value* out of a set and then just... it's a value.
--
---
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/?hl=en.
------=_Part_287_11398672.1365507625493
Content-Type: text/html; charset=ISO-8859-1
That refers to moving a node out of one set and into another, whereas I am referring to moving the *value* out of a set and then just... it's a value.
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
------=_Part_287_11398672.1365507625493--
.
Author: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= <lrdxgm@gmail.com>
Date: Tue, 9 Apr 2013 06:11:14 -0700 (PDT)
Raw View
------=_Part_5299_1564840.1365513074550
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
2013. =E1prilis 9., kedd 2:36:46 UTC+2 id=F5pontban jgot...@gmail.com a=20
k=F6vetkez=F5t =EDrta:
>
> While this would be useful, there is too much chance of two types being=
=20
> equality-comparable but having incompatible hashes. For example, under g=
cc=20
> 8.0,=20
> std::hash<long>(-1L) =3D=3D 18446744073709551615
> and
> std::hash<double>(-1.0) =3D=3D 11078049357879903929
>
>
>
If a =3D=3D b, then I would expect that hash(a) =3D=3D hash(b). If a langua=
ge does=20
not exhibit this, then there is something wrong - from a user's perspective=
=20
hashing is useless if it produces different results for equal values...=20
Implementer's perspective is a different question..
Regards, Robert
PS: What is gcc 8.0?
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_5299_1564840.1365513074550
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>2013. =E1prilis 9., kedd 2:36:46 UTC+2 id=F5pontban jgot...@gmail.c=
om a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Whi=
le this would be useful, there is too much chance of two types being equali=
ty-comparable but having incompatible hashes. For example, under gcc =
8.0, <div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,1=
87,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><di=
v><span style=3D"color:#000">std</span><span style=3D"color:#660">::</span>=
<span style=3D"color:#000">hash</span><span style=3D"color:#080"><long&g=
t;</span><span style=3D"color:#660">(-</span><span style=3D"color:#066">1L<=
/span><span style=3D"color:#660">)</span><span style=3D"color:#000"> </span=
><span style=3D"color:#660">=3D=3D</span><span style=3D"color:#000"> </span=
><span style=3D"color:#066">18446744073709551615</span><span style=3D"color=
:#000"><br></span></div></code></div>and<br><div style=3D"background-color:=
rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-wi=
dth:1px;word-wrap:break-word"><code><div><span style=3D"color:#000">std</sp=
an><span style=3D"color:#660">::</span><span style=3D"color:#000">hash</spa=
n><span style=3D"color:#080"><double></span><span style=3D"color:#660=
">(-</span><span style=3D"color:#066">1.0</span><span style=3D"color:#660">=
)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=3D=
=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#066">110=
78049357879903929</span><span style=3D"color:#000"><br></span></div></code>=
</div><br><br></blockquote><div><br>If a =3D=3D b, then I would expect that=
hash(a) =3D=3D hash(b). If a language does not exhibit this, then there is=
something wrong - from a user's perspective hashing is useless if it produ=
ces different results for equal values... Implementer's perspective is a di=
fferent question..<br><br>Regards, Robert<br><br>PS: What is gcc 8.0?<br></=
div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_5299_1564840.1365513074550--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Tue, 9 Apr 2013 06:21:39 -0700 (PDT)
Raw View
------=_Part_2764_24956213.1365513699370
Content-Type: text/plain; charset=ISO-8859-1
He probably means 4.8.0. The Standard doesn't currently require any such
thing for cross-type hashes in the general case, only a few specific
instances.
--
---
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/?hl=en.
------=_Part_2764_24956213.1365513699370
Content-Type: text/html; charset=ISO-8859-1
He probably means 4.8.0. The Standard doesn't currently require any such thing for cross-type hashes in the general case, only a few specific instances.
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
------=_Part_2764_24956213.1365513699370--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Tue, 9 Apr 2013 11:56:53 -0700 (PDT)
Raw View
------=_Part_5542_15378143.1365533813588
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Op dinsdag 9 april 2013 15:11:14 UTC+2 schreef R=F3bert D=E1vid het volgend=
e:
>
> If a =3D=3D b, then I would expect that hash(a) =3D=3D hash(b). If a lang=
uage does=20
> not exhibit this, then there is something wrong - from a user's perspecti=
ve=20
> hashing is useless if it produces different results for equal values...
>
>
How'd you implement that for float vs int?
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_5542_15378143.1365533813588
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>Op dinsdag 9 april 2013 15:11:14 UTC+2 schreef R=F3bert D=E1vid het=
volgende:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">If a =3D=3D b, then =
I would expect that hash(a) =3D=3D hash(b). If a language does not exhibit =
this, then there is something wrong - from a user's perspective hashing is =
useless if it produces different results for equal values...<br><div><br></=
div></blockquote><div><br></div><div>How'd you implement that for float vs =
int?</div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_5542_15378143.1365533813588--
.
Author: jgottman6@gmail.com
Date: Tue, 9 Apr 2013 19:22:47 -0700 (PDT)
Raw View
------=_Part_6377_22165865.1365560567186
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, April 9, 2013 6:58:15 AM UTC-4, DeadMG wrote:
>
> Actually, I don't believe that exact use case *is* in the paper. And,
> whilst it's nice, it would depend on std::hash<const char*> treating it's
> argument like a C string rather than a generic pointer, and I don't know if
> it does. If so, then that would certainly be a nice use case- and you could
> certainly provide a custom hasher for one lookup that could perform this
> using another of the features in N3573.
>
> Whilst I admit that I overlooked implicit conversions in this case, it's
> not a breaking problem, I'll just have to provide a new name, like, find_by
> or some such (and the same for erasure). That also means I'd have to use
> SFINAE to limit operator[] too, since that cannot be given another name, or
> perhaps some kind of trait. It would have been nice to have something like
>
> template<typename T, typename U> void find(std::unordered_set<T> t, U&& u)
> {
> t.find(u);
> }
>
> function for any U, I doubt any such code exists, so I'm not that bothered
> by losing it.
>
Actually, this is possible. You just need to overload operator() in your
hash object. Thus, for hash<unique_ptr<X>>, as well as defining
operator()(const unique_ptr<X> &), you would also define operator()(X *).
Then, your templated find method would always call
hash<unique_ptr<X>>()(u), but which overload it chooses would depend on the
type of u.
Joe Gottman
--
---
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/?hl=en.
------=_Part_6377_22165865.1365560567186
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br>On Tuesday, April 9, 2013 6:58:15 AM UTC-4, DeadMG wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">Actually, I don't believe that exact use cas=
e *is* in the paper. And, whilst it's nice, it would depend on std::hash<=
;const char*> treating it's argument like a C string rather than a gener=
ic pointer, and I don't know if it does. If so, then that would certainly b=
e a nice use case- and you could certainly provide a custom hasher for one =
lookup that could perform this using another of the features in N3573.<div>=
<br></div><div>Whilst I admit that I overlooked implicit conversions in thi=
s case, it's not a breaking problem, I'll just have to provide a new name, =
like, find_by or some such (and the same for erasure). That also means I'd =
have to use SFINAE to limit operator[] too, since that cannot be given anot=
her name, or perhaps some kind of trait. It would have been nice to have so=
mething like</div><div><br></div><div style=3D"background-color:rgb(250,250=
,250);border:1px solid rgb(187,187,187);word-wrap:break-word"><code><div><s=
pan style=3D"color:#008">template</span><span style=3D"color:#660"><</sp=
an><span style=3D"color:#008">typename</span><span style=3D"color:#000"> T<=
/span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </span=
><span style=3D"color:#008">typename</span><span style=3D"color:#000"> U</s=
pan><span style=3D"color:#660">></span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#008">void</span><span style=3D"color:#000"> find</s=
pan><span style=3D"color:#660">(</span><span style=3D"color:#000">std</span=
><span style=3D"color:#660">::</span><span style=3D"color:#000">unordered_s=
et</span><span style=3D"color:#660"><</span><span style=3D"color:#000">T=
</span><span style=3D"color:#660">></span><span style=3D"color:#000"> t<=
/span><span style=3D"color:#660">,</span><span style=3D"color:#000"> U</spa=
n><span style=3D"color:#660">&&</span><span style=3D"color:#000"> u=
</span><span style=3D"color:#660">)</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#660">{</span><span style=3D"color:#000"><br> =
t</span><span style=3D"color:#660">.</span><span style=3D"color:#000=
">find</span><span style=3D"color:#660">(</span><span style=3D"color:#000">=
u</span><span style=3D"color:#660">);</span><span style=3D"color:#000"><br>=
</span><span style=3D"color:#660">}</span></div></code></div><div><br></div=
><div>function for any U, I doubt any such code exists, so I'm not that bot=
hered by losing it.<br></div></blockquote><div><br> <br>Actually, this=
is possible. You just need to overload operator() in your hash objec=
t. Thus, for hash<unique_ptr<X>>, as well as defining ope=
rator()(const unique_ptr<X> &), you would also define operator()(=
X *). Then, your templated find method would always call hash<uniq=
ue_ptr<X>>()(u), but which overload it chooses would depend on the=
type of u.<br><br>Joe Gottman<br></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_6377_22165865.1365560567186--
.
Author: Jim Porter <jvp4846@g.rit.edu>
Date: Fri, 11 Apr 2014 23:29:23 -0700 (PDT)
Raw View
------=_Part_437_24753774.1397284163843
Content-Type: text/plain; charset=UTF-8
Sorry for resurrecting a dead thread, but I just came across this issue
doing something similar to the motivation in N3573.
On Monday, April 8, 2013 7:36:46 PM UTC-5, jgot...@gmail.com wrote:
>
> N3573 suggests allowing lookup into unordered sets and maps by alternative
> keys, as long as operator== can compare both types and the hashes of the
> two types are compatible. The use case given is
>
> std::unordered_map<std::string, int> map;
> map.find("foo"); // We don't have to construct string("foo") to do the
> find.
>
> [snip]
>
> Thus, if N3573 were accepted, this code would fail:
>
> std:unordered_set<double> s;
> s.insert(-1L); // Internally converts -1L to -1.0 and hashes that
> assert(s.find(-1L) != s.end()); // fails. find calls hash<long>(-1L) and
> gets the wrong bucket
>
>
Would it be sufficient for std::unordered_set to default to using
std::hash<Key> instead of std::hash<void>? This would force you to
explicitly enable this behavior, preventing bad things from happening by
default (essentially like std::map and std::less<void>). I think you'd
still get some degree of assurance that the key type is compatible with the
type you're using in find() thanks to std::equal_to (again, much like
std::less).
In any case, evil implementations of operator< could cause the same problem
in std::map.
- Jim
--
---
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/.
------=_Part_437_24753774.1397284163843
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Sorry for resurrecting a dead thread, but I just came acro=
ss this issue doing something similar to the motivation in N3573.<br><br>On=
Monday, April 8, 2013 7:36:46 PM UTC-5, jgot...@gmail.com wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">N3573 suggests allowing lookup into unor=
dered sets and maps by alternative keys, as long as operator=3D=3D can comp=
are both types and the hashes of the two types are compatible. The us=
e case given is<br><br><div style=3D"background-color:rgb(250,250,250);bord=
er-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:bre=
ak-word"><code><div><code><span style=3D"color:#000"> std</span><span =
style=3D"color:#660">::</span><span style=3D"color:#000">unordered_map</spa=
n><span style=3D"color:#660"><</span><span style=3D"color:#000">std</spa=
n><span style=3D"color:#660">::</span><span style=3D"color:#008">strin<wbr>=
g</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#008">int</span><span style=3D"color:#660">></sp=
an><span style=3D"color:#000"> map</span><span style=3D"color:#660">;</span=
><span style=3D"color:#000"><br> map</span><span style=3D"color:#660">=
..</span><span style=3D"color:#000">find</span><span style=3D"color:#660">(<=
/span><span style=3D"color:#080">"foo"</span><span style=3D"color:#660">);<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#800">// We d=
on't have to construct string("foo") to do the find.</span><span style=3D"c=
olor:#000"><br></span></code></div></code></div><br></blockquote><div>[snip=
] <br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>Thus, if N3573=
were accepted, this code would fail:<br><br><div style=3D"background=
-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;bo=
rder-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#000">=
std</span><span style=3D"color:#660">:</span><span style=3D"color:#000">uno=
rdered_set</span><span style=3D"color:#080"><double></span><span styl=
e=3D"color:#000"> s</span><span style=3D"color:#660">;</span><span style=3D=
"color:#000"><br>s</span><span style=3D"color:#660">.</span><span style=3D"=
color:#000">insert</span><span style=3D"color:#660">(-</span><span style=3D=
"color:#066">1L</span><span style=3D"color:#660">);</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#800">// Internally converts -1L to =
-1.0 and hashes that</span><span style=3D"color:#000"><br></span><span styl=
e=3D"color:#008">assert</span><span style=3D"color:#660">(</span><span styl=
e=3D"color:#000">s</span><span style=3D"color:#660">.</span><span style=3D"=
color:#000">find</span><span style=3D"color:#660">(-</span><span style=3D"c=
olor:#066">1L</span><span style=3D"color:#660">)</span><span style=3D"color=
:#000"> </span><span style=3D"color:#660">!=3D</span><span style=3D"color:#=
000"> s</span><span style=3D"color:#660">.</span><span style=3D"color:#008"=
>end</span><span style=3D"color:#660">());</span><span style=3D"color:#000"=
> </span><span style=3D"color:#800">// fails. find calls hash<long>(-=
1L) and gets the wrong bucket</span><span style=3D"color:#000"><br></span><=
/div></code></div><br></blockquote><div><br>Would it be sufficient for std:=
:unordered_set to default to using std::hash<Key> instead of std::has=
h<void>? This would force you to explicitly enable this behavior, pre=
venting bad things from happening by default (essentially like std::map and=
std::less<void>). I think you'd still get some degree of assurance t=
hat the key type is compatible with the type you're using in find() thanks =
to std::equal_to (again, much like std::less).<br><br>In any case, evil imp=
lementations of operator< could cause the same problem in std::map.<br><=
br>- Jim<br></div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_437_24753774.1397284163843--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Wed, 16 Apr 2014 10:34:29 -0700 (PDT)
Raw View
------=_Part_1385_13208538.1397669669703
Content-Type: text/plain; charset=UTF-8
No, no it would not. Consider the original motivation in the paper-
unique_ptr<T> and T*. Since there's already a hash specialization for
unique_ptr, you could not add one for T* later. Obviously for a Standard
type this is not a big deal but you cannot go back and enable it for, say,
boost::shared_ptr after the fact. This would only work if the author of
some given T knows all the possible types U which might be meaningful here,
and that's just not a very good system.
Better would be to use a separate trait to control which types are and are
not eligible.
--
---
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/.
------=_Part_1385_13208538.1397669669703
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">No, no it would not. Consider the original motivation in t=
he paper- unique_ptr<T> and T*. Since there's already a hash speciali=
zation for unique_ptr, you could not add one for T* later. Obviously for a =
Standard type this is not a big deal but you cannot go back and enable it f=
or, say, boost::shared_ptr after the fact. This would only work if the auth=
or of some given T knows all the possible types U which might be meaningful=
here, and that's just not a very good system.<br><br>Better would be to us=
e a separate trait to control which types are and are not eligible.<br></di=
v>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1385_13208538.1397669669703--
.
Author: Jim Porter <jvp4846@g.rit.edu>
Date: Thu, 17 Apr 2014 15:19:18 -0700 (PDT)
Raw View
------=_Part_916_19459996.1397773158988
Content-Type: text/plain; charset=UTF-8
On Wednesday, April 16, 2014 12:34:29 PM UTC-5, DeadMG wrote:
>
> No, no it would not. Consider the original motivation in the paper-
> unique_ptr<T> and T*. Since there's already a hash specialization for
> unique_ptr, you could not add one for T* later.
>
Ah, yeah, that would be a problem. (I assume the issue here is divergent
hash specializations
Better would be to use a separate trait to control which types are and are
> not eligible.
>
If N3573 dropped the hash<void> proposal, you could probably handle this by
requiring people to write their own hashers that only accept the eligible
types.
Maybe I should explain the use case I care about at the moment: I have a
map whose key_type is a tuple of value types, but I want to be able to
perform lookups on the map with a tuple of reference types. Implementing my
own hash function that just combines the hashes of the tuple's members
would be totally acceptable for me.
My original idea before seeing N3573 was to add a member function to
unordered_map that retrieves the bucket associated with a particular hash
value. Then I could just perform the hash myself and do the lookup of the
value on my own. That's obviously not the ideal way to do this, although I
do think that would be a (somewhat) useful function to have as a complement
to unordered_map::bucket(const key_type&).
- Jim
--
---
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/.
------=_Part_916_19459996.1397773158988
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, April 16, 2014 12:34:29 PM UTC-5, DeadMG wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">No, no it =
would not. Consider the original motivation in the paper- unique_ptr<T&g=
t; and T*. Since there's already a hash specialization for unique_ptr, you =
could not add one for T* later. </div></blockquote><div><br>Ah, yeah, that =
would be a problem. (I assume the issue here is divergent hash specializati=
ons<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">Better would be to use a separate trait to control which types are and =
are not eligible.<br></div></blockquote><div><br>If N3573 dropped the hash&=
lt;void> proposal, you could probably handle this by requiring people to=
write their own hashers that only accept the eligible types.<br><br>Maybe =
I should explain the use case I care about at the moment: I=20
have a map whose key_type is a tuple of value types, but I want to be=20
able to perform lookups on the map with a tuple of reference types. Impleme=
nting my own hash function that just combines the hashes of the tuple's mem=
bers would be totally acceptable for me.<br><br>My original idea before see=
ing N3573 was to add a member function to unordered_map that retrieves the =
bucket associated with a particular hash value. Then I could just perform t=
he hash myself and do the lookup of the value on my own. That's obviously n=
ot the ideal way to do this, although I do think that would be a (somewhat)=
useful function to have as a complement to unordered_map::bucket(const key=
_type&).<br><br>- Jim<br></div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_916_19459996.1397773158988--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Fri, 18 Apr 2014 10:52:41 -0400
Raw View
On Apr 17, 2014, at 6:19 PM, Jim Porter <jvp4846@g.rit.edu> wrote:
> Maybe I should explain the use case I care about at the moment: I have a =
map whose key_type is a tuple of value types, but I want to be able to perf=
orm lookups on the map with a tuple of reference types. Implementing my own=
hash function that just combines the hashes of the tuple's members would b=
e totally acceptable for me.
With this proposal:
http://htmlpreview.github.io/?https://github.com/HowardHinnant/papers/blob/=
master/hashing.html
which has not yet been submitted, one can do this:
char a =3D 'a';
int i =3D 3;
double d =3D 2.5;
auto t1 =3D std::make_tuple(a, i, d);
auto t2 =3D std::tie (a, i, d);
assert(uhash<>{}(t1) =3D=3D uhash<>{}(t2));
One can also easily change the assert to:
assert(uhash<fnv1a>{}(t1) =3D=3D uhash<fnv1a>{}(t2));
or
assert(uhash<spooky>{}(t1) =3D=3D uhash<spooky>{}(t2));
or
assert(uhash<siphash>{}(t1) =3D=3D uhash<siphash>{}(t2));
Howard
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Jim Porter <jvp4846@g.rit.edu>
Date: Sat, 19 Apr 2014 08:46:48 -0700 (PDT)
Raw View
------=_Part_76_31921248.1397922408586
Content-Type: text/plain; charset=UTF-8
On Friday, April 18, 2014 9:52:41 AM UTC-5, Howard Hinnant wrote:
>
> On Apr 17, 2014, at 6:19 PM, Jim Porter <jvp...@g.rit.edu <javascript:>>
> wrote:
>
> > Maybe I should explain the use case I care about at the moment: I have a
> map whose key_type is a tuple of value types, but I want to be able to
> perform lookups on the map with a tuple of reference types. Implementing my
> own hash function that just combines the hashes of the tuple's members
> would be totally acceptable for me.
>
> With this proposal:
>
>
> http://htmlpreview.github.io/?https://github.com/HowardHinnant/papers/blob/master/hashing.html
>
I suppose this would still have the problem mentioned in the original post,
namely that uhash<>{}(1.0) != uhash<>{}(1). However, I think this would
resolve DeadMG's issue by providing a specification for what data is hashed
for each type. Thus, you wouldn't have divergent specializations of hash
functions (or at least, it would be no more likely than writing an "evil"
less-than operator).
There'd still need to be some way of explicitly enabling the heterogeneous
extensions to unordered_map, though.
- Jim
--
---
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/.
------=_Part_76_31921248.1397922408586
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, April 18, 2014 9:52:41 AM UTC-5, Howard Hinnant=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Apr 17, 2014, at 6:1=
9 PM, Jim Porter <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"TEtY9D348k8J" onmousedown=3D"this.href=3D'javascript:';return =
true;" onclick=3D"this.href=3D'javascript:';return true;">jvp...@g.rit.edu<=
/a>> wrote:
<br>
<br>> Maybe I should explain the use case I care about at the moment: I =
have a map whose key_type is a tuple of value types, but I want to be able =
to perform lookups on the map with a tuple of reference types. Implementing=
my own hash function that just combines the hashes of the tuple's members =
would be totally acceptable for me.
<br>
<br>With this proposal:
<br>
<br><a href=3D"http://htmlpreview.github.io/?https://github.com/HowardHinna=
nt/papers/blob/master/hashing.html" target=3D"_blank" onmousedown=3D"this.h=
ref=3D'http://www.google.com/url?q\75http%3A%2F%2Fhtmlpreview.github.io%2F%=
3Fhttps%3A%2F%2Fgithub.com%2FHowardHinnant%2Fpapers%2Fblob%2Fmaster%2Fhashi=
ng.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHP0pXriy_dMNhgyflMJ_r9qoA63Q';re=
turn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2=
F%2Fhtmlpreview.github.io%2F%3Fhttps%3A%2F%2Fgithub.com%2FHowardHinnant%2Fp=
apers%2Fblob%2Fmaster%2Fhashing.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHP0=
pXriy_dMNhgyflMJ_r9qoA63Q';return true;">http://htmlpreview.github.io/?<wbr=
>https://github.com/<wbr>HowardHinnant/papers/blob/<wbr>master/hashing.html=
</a>
<br></blockquote><div><br>I suppose this would still have the problem menti=
oned in the original post, namely that uhash<>{}(1.0) !=3D uhash<&=
gt;{}(1). However, I think this would resolve DeadMG's issue by providing a=
specification for what data is hashed for each type. Thus, you wouldn't ha=
ve divergent specializations of hash functions (or at least, it would be no=
more likely than writing an "evil" less-than operator).<br><br>There'd sti=
ll need to be some way of explicitly enabling the heterogeneous extensions =
to unordered_map, though.<br><br>- Jim<br></div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_76_31921248.1397922408586--
.