------=_Part_794_25771973.1380316824748
Content-Type: text/plain; charset=ISO-8859-1

It looks like the upcoming heterogeneous lookup for associative containers
will allow me to do something I've wanted to do ever since I started using
unique_ptr: utilize maps and sets with unique_ptr as the key type. The way
C++11 does it now, you obviously can't use unique_ptrs for lookup (since
the ones owned by the collection are supposed to be unique). But in the
upcoming standard, a custom Compare functor could allow you to use raw
pointers for lookup. This Stack Overflow question goes over the issue
nicely:
http://stackoverflow.com/questions/18939882/raw-pointer-lookup-for-sets-of-unique-ptrs

But what about std::unordered_map and std::unordered_set? I think it would
be great if I could practically use std::unique_ptr as the key type in
those templates as well. For regular std::set and std::map in the upcoming
standard, if Compare::is_transparent exists, then overloads for find() are
created which take any arguments type-compatible with Compare. For
std::unordered_set and std::unordered_map, why not add similar find()
overloads if Hash and KeyEqual have is_transparent?

I'm not suggesting we add is_transparent to the existing std::hash and
std::equal_to functors, just that we make the option available for custom
Hash and KeyEqual functors.

This wouldn't just allow unique_ptrs to be used as an unordered_map or
unordered_set key type, but would allow for an optimization when
std::string is the key type as well, similar to the example given in the
introduction to the regular heterogeneous lookup proposal (
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3657.htm). If
there were, say, a functor named std::string_hash (or, basic_string_hash,
etc.) that defined is_transparent, accepted both std::string and C strings,
and calculated the same hash values when their contents were the same, then
there would be no need to construct a temporary std::string when doing a
lookup using a C string.

--

---
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_794_25771973.1380316824748
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It looks like the upcoming heterogeneous lookup for associ=
ative containers will allow me to do something I've wanted to do ever since=
 I started using unique_ptr: utilize maps and sets with unique_ptr as the k=
ey type. The way C++11 does it now, you obviously can't use unique_ptrs for=
 lookup (since the ones owned by the collection are supposed to be unique).=
 But in the upcoming standard, a custom Compare functor could allow you to =
use raw pointers for lookup. This Stack Overflow question goes over the iss=
ue nicely: <a href=3D"http://stackoverflow.com/questions/18939882/raw-point=
er-lookup-for-sets-of-unique-ptrs">http://stackoverflow.com/questions/18939=
882/raw-pointer-lookup-for-sets-of-unique-ptrs</a><br><br>But what about st=
d::unordered_map and std::unordered_set? I think it would be great if I cou=
ld practically use std::unique_ptr as the key type in those templates as we=
ll. For regular std::set and std::map in the upcoming standard, if Compare:=
:is_transparent exists, then overloads for find() are created which take an=
y arguments type-compatible with Compare. For std::unordered_set and std::u=
nordered_map, why not add similar find() overloads if Hash and KeyEqual hav=
e is_transparent?<br><br>I'm not suggesting we add is_transparent to the ex=
isting std::hash and std::equal_to functors, just that we make the option a=
vailable for custom Hash and KeyEqual functors.<br><br>This wouldn't just a=
llow unique_ptrs to be used as an unordered_map or unordered_set key type, =
but would allow for an optimization when std::string is the key type as wel=
l, similar to the example given in the introduction to the regular heteroge=
neous lookup proposal (<a href=3D"http://www.open-std.org/JTC1/SC22/WG21/do=
cs/papers/2013/n3657.htm">http://www.open-std.org/JTC1/SC22/WG21/docs/paper=
s/2013/n3657.htm</a>). If there were, say, a functor named std::string_hash=
 (or, basic_string_hash, etc.) that defined is_transparent, accepted both s=
td::string and C strings, and calculated the same hash values when their co=
ntents were the same, then there would be no need to construct a temporary =
std::string when doing a lookup using a C string.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_794_25771973.1380316824748--

.