------=_Part_982_1917225101.1443929113402
Content-Type: multipart/alternative;
 boundary="----=_Part_983_566940569.1443929113402"

------=_Part_983_566940569.1443929113402
Content-Type: text/plain; charset=UTF-8

Unless I'm missing something (wouldn't surprise me), there's no way
specific in the paper for user code to extract the resulting hash from
hash_code or the HashCode concept.

The sample implementation code has a member result_type alias and an
`operator result_type()` but those interfaces are not present in the paper.

Seems like a small but rather critical missing piece. :)

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0029r0.html

--

---
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_983_566940569.1443929113402
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Unless I&#39;m missing something (wouldn&#39;t surpri=
se me), there&#39;s no way specific in the paper for user code to extract t=
he resulting hash from hash_code or the HashCode concept.<br></div><div><br=
></div><div>The sample implementation code has a member result_type alias a=
nd an `operator result_type()` but those interfaces are not present in the =
paper.</div><div><br></div><div>Seems like a small but rather critical miss=
ing piece. :)</div><div><br></div><div>http://www.open-std.org/jtc1/sc22/wg=
21/docs/papers/2015/p0029r0.html<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&quot; 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_983_566940569.1443929113402--
------=_Part_982_1917225101.1443929113402--

.

--001a114786f08e9fd705215ddad1
Content-Type: text/plain; charset=UTF-8

The API for extracting a hash value, and symmetrically the API for
initializing the HashCode, is deliberately left unspecified. In the case of
std::hash_code it doesn't matter, because only std::hash needs to be aware
of those details. Other HashCode types can provide similar functor
wrappers, or explicitly specify those APIs however they choose.

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.

On Sat, Oct 3, 2015 at 8:25 PM, Sean Middleditch <sean.middleditch@gmail.com
> wrote:

> Unless I'm missing something (wouldn't surprise me), there's no way
> specific in the paper for user code to extract the resulting hash from
> hash_code or the HashCode concept.
>
> The sample implementation code has a member result_type alias and an
> `operator result_type()` but those interfaces are not present in the paper.
>
> Seems like a small but rather critical missing piece. :)
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0029r0.html
>

--

---
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/.

--001a114786f08e9fd705215ddad1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The API for extracting a hash value, and symmetrically the=
 API for initializing the HashCode, is deliberately left unspecified. In th=
e case of std::hash_code it doesn&#39;t matter, because only std::hash need=
s to be aware of those details. Other HashCode types can provide similar fu=
nctor wrappers, or explicitly specify those APIs however they choose.<div><=
br></div><div>The initialization API is unspecified because it depends on t=
he implementation details of the HashCode (e.g. hashing::farmhash needs a p=
ointer to its state as an input). The value-extraction API is unspecified b=
ecause it&#39;s unsafe: in many cases it will leave the HashCode in an unus=
able state. I solved that in the prototype by making it rvalue-ref qualifie=
d, but then I realized there&#39;s no need to specify it at all (particular=
ly when the initialization API is also unspecified), and an unspecified API=
 is simpler, safer, and harder to bikeshed.</div><div><br></div><div>I had =
thought I spelled this out in the paper somewhere, but I can&#39;t immediat=
ely find it, so that may be an oversight on my part.<br></div></div><div cl=
ass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Oct 3, 2015 at 8=
:25 PM, Sean Middleditch <span dir=3D"ltr">&lt;<a href=3D"mailto:sean.middl=
editch@gmail.com" target=3D"_blank">sean.middleditch@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Unless I&=
#39;m missing something (wouldn&#39;t surprise me), there&#39;s no way spec=
ific in the paper for user code to extract the resulting hash from hash_cod=
e or the HashCode concept.<br></div><div><br></div><div>The sample implemen=
tation code has a member result_type alias and an `operator result_type()` =
but those interfaces are not present in the paper.</div><div><br></div><div=
>Seems like a small but rather critical missing piece. :)</div><div><br></d=
iv><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/=
p0029r0.html" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs=
/papers/2015/p0029r0.html</a><br></div></div></blockquote></div><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&quot; 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 />

--001a114786f08e9fd705215ddad1--

.

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?

> 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?

> 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.

--
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/.

.

--001a114363ac08412c05215eec98
Content-Type: text/plain; charset=UTF-8

On Mon, Oct 5, 2015 at 10:07 AM Thiago Macieira <thiago@macieira.org> 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<T>.  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 <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
> 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 <typename T>
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 <typename T>
  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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Oct 5,=
 2015 at 10:07 AM Thiago Macieira &lt;<a href=3D"mailto:thiago@macieira.org=
">thiago@macieira.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">On Monday 05 October 2015 09:17:45 &#39;Geoffrey Romer&#39; via ISO C++ S=
tandard -<br>
Future Proposals wrote:<br>
&gt; The API for extracting a hash value, and symmetrically the API for<br>
&gt; initializing the HashCode, is deliberately left unspecified.<br>
<br>
So if I want to write a new portable container that relies on hashing, I<br=
>
can&#39;t? What&#39;s the rationale for that?<br></blockquote><div><br></di=
v><div>The proposal doesn&#39;t change the requirements on the hash-functio=
n callable itself.=C2=A0 If you want to implement a portable container that=
 relies on hashing, you have a template parameter for the hash function whi=
ch adheres to the same interface as std::hash&lt;T&gt;.=C2=A0 It is callabl=
e with the element type and returns a size_t.</div><div><pre style=3D"color=
:rgb(0,0,0);line-height:normal">~/.ssh/id_rsa_github</pre></div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
<br>
&gt; In the case of<br>
&gt; std::hash_code it doesn&#39;t matter, because only std::hash needs to =
be aware<br>
&gt; of those details.<br>
<br>
Most definitely not. I started with an example that disagrees with this<br>
perspective.<br>
<br>
&gt; Other HashCode types can provide similar functor<br>
&gt; wrappers, or explicitly specify those APIs however they choose.<br>
<br>
So if I write my own element type T, I need to specify its hashing function=
<br>
for std::unordered_map and SomeOtherHash?<br></blockquote><div><br></div><d=
iv>If you write your own element type T, you need to implement one of:</div=
><div><br></div><div>std::hash_code hash_value(std::hash_code, T);</div><di=
v><br></div><div>Or (preferred, to support a variety of algorithms):</div><=
div><br></div><div>template &lt;typename H&gt;</div><div>H hash_value(H, T)=
;</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
&gt; The initialization API is unspecified because it depends on the<br>
&gt; implementation details of the HashCode (e.g. hashing::farmhash needs a=
<br>
&gt; pointer to its state as an input). The value-extraction API is unspeci=
fied<br>
&gt; because it&#39;s unsafe: in many cases it will leave the HashCode in a=
n<br>
&gt; unusable state. I solved that in the prototype by making it rvalue-ref=
<br>
&gt; qualified, but then I realized there&#39;s no need to specify it at al=
l<br>
&gt; (particularly when the initialization API is also unspecified), and an=
<br>
&gt; unspecified API is simpler, safer, and harder to bikeshed.<br>
&gt;<br>
&gt; I had thought I spelled this out in the paper somewhere, but I can&#39=
;t<br>
&gt; immediately find it, so that may be an oversight on my part.<br>
<br>
I find that those reasons invalidate the proposal.<br>
<br>
If I can&#39;t use them in my own hashing container, they&#39;re unusable.<=
br></blockquote><div><br></div><div>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.</div><div><br></div><div>template &lt;typenam=
e T&gt;</div><div>struct hash {</div><div>=C2=A0 size_t operator() (const T=
&amp; value) const {</div><div>=C2=A0 =C2=A0 std::hash_code state =3D __imp=
lementation_defined_init();</div><div>=C2=A0 =C2=A0 state =3D hash_value(st=
ate, value);</div><div>=C2=A0 =C2=A0 return __implementation_defined_extrac=
t_value(state);</div><div>=C2=A0 }</div><div>};</div><div><br></div><div>Or=
:<br></div><div><br></div><div>struct MyHashCode {</div><div>=C2=A0 ...</di=
v><div>=C2=A0private:</div><div>=C2=A0 =C2=A0 ...</div><div>=C2=A0 =C2=A0 f=
riend class MyHash;</div><div>=C2=A0 =C2=A0 operator size_t() const;</div><=
div>};</div><div><br></div><div>struct MyHash {</div><div>=C2=A0 template &=
lt;typename T&gt;</div><div>=C2=A0 size_t operator()(const T&amp; value) co=
nst {</div><div>=C2=A0 =C2=A0 MyHashCode state;</div><div>=C2=A0 =C2=A0 ret=
urn hash_value(state, t);</div><div>=C2=A0 }</div><div>};</div><div><br></d=
iv><div>Essentially, the only part which remains undefined is the internal =
interface between the top-level hash algorithm and its internal state.</div=
><div><br></div><div>--Shahms</div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535=
8<br>
<br>
--<br>
<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 <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote></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&quot; 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 />

--001a114363ac08412c05215eec98--

.

--001a1143a3e824104905215ef3e9
Content-Type: text/plain; charset=UTF-8

On Mon, Oct 5, 2015 at 10:34 AM Shahms King <shahms.king@gmail.com> wrote:

> On Mon, Oct 5, 2015 at 10:07 AM Thiago Macieira <thiago@macieira.org>
> 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<T>.  It is callable with the element
> type and returns a size_t.
>
> ~/.ssh/id_rsa_github
>
>
Ignore that line, there was an accidental ^V in there :-\

--Shahms


>
>
>>
>> > 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 <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
>> 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 <typename T>
> 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 <typename T>
>   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/.

--001a1143a3e824104905215ef3e9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon=
, Oct 5, 2015 at 10:34 AM Shahms King &lt;<a href=3D"mailto:shahms.king@gma=
il.com">shahms.king@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On M=
on, Oct 5, 2015 at 10:07 AM Thiago Macieira &lt;<a href=3D"mailto:thiago@ma=
cieira.org" target=3D"_blank">thiago@macieira.org</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">On Monday 05 October 2015 09:17:45 &#39;Geoff=
rey Romer&#39; via ISO C++ Standard -<br>
Future Proposals wrote:<br>
&gt; The API for extracting a hash value, and symmetrically the API for<br>
&gt; initializing the HashCode, is deliberately left unspecified.<br>
<br>
So if I want to write a new portable container that relies on hashing, I<br=
>
can&#39;t? What&#39;s the rationale for that?<br></blockquote><div><br></di=
v></div></div><div dir=3D"ltr"><div class=3D"gmail_quote"><div>The proposal=
 doesn&#39;t change the requirements on the hash-function callable itself.=
=C2=A0 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&lt;T&gt;.=C2=A0 It is callable with the element=
 type and returns a size_t.</div><div><pre style=3D"color:rgb(0,0,0);line-h=
eight:normal">~/.ssh/id_rsa_github</pre></div></div></div></blockquote><div=
><br></div><div>Ignore that line, there was an accidental ^V in there :-\</=
div><div><br></div><div>--Shahms</div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">
<br>
&gt; In the case of<br>
&gt; std::hash_code it doesn&#39;t matter, because only std::hash needs to =
be aware<br>
&gt; of those details.<br>
<br>
Most definitely not. I started with an example that disagrees with this<br>
perspective.<br>
<br>
&gt; Other HashCode types can provide similar functor<br>
&gt; wrappers, or explicitly specify those APIs however they choose.<br>
<br>
So if I write my own element type T, I need to specify its hashing function=
<br>
for std::unordered_map and SomeOtherHash?<br></blockquote><div><br></div></=
div></div><div dir=3D"ltr"><div class=3D"gmail_quote"><div>If you write you=
r own element type T, you need to implement one of:</div><div><br></div><di=
v>std::hash_code hash_value(std::hash_code, T);</div><div><br></div><div>Or=
 (preferred, to support a variety of algorithms):</div><div><br></div><div>=
template &lt;typename H&gt;</div><div>H hash_value(H, T);</div></div></div>=
<div dir=3D"ltr"><div class=3D"gmail_quote"><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
<br>
&gt; The initialization API is unspecified because it depends on the<br>
&gt; implementation details of the HashCode (e.g. hashing::farmhash needs a=
<br>
&gt; pointer to its state as an input). The value-extraction API is unspeci=
fied<br>
&gt; because it&#39;s unsafe: in many cases it will leave the HashCode in a=
n<br>
&gt; unusable state. I solved that in the prototype by making it rvalue-ref=
<br>
&gt; qualified, but then I realized there&#39;s no need to specify it at al=
l<br>
&gt; (particularly when the initialization API is also unspecified), and an=
<br>
&gt; unspecified API is simpler, safer, and harder to bikeshed.<br>
&gt;<br>
&gt; I had thought I spelled this out in the paper somewhere, but I can&#39=
;t<br>
&gt; immediately find it, so that may be an oversight on my part.<br>
<br>
I find that those reasons invalidate the proposal.<br>
<br>
If I can&#39;t use them in my own hashing container, they&#39;re unusable.<=
br></blockquote><div><br></div></div></div><div dir=3D"ltr"><div class=3D"g=
mail_quote"><div>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 mech=
anism by which user-defined types can supply their data to the hash functio=
n, not the interface for retrieving final values from that hash function.=
=C2=A0 The high-level API for retrieving a hash value from an object is unc=
hanged, e.g.</div><div><br></div><div>template &lt;typename T&gt;</div><div=
>struct hash {</div><div>=C2=A0 size_t operator() (const T&amp; value) cons=
t {</div><div>=C2=A0 =C2=A0 std::hash_code state =3D __implementation_defin=
ed_init();</div><div>=C2=A0 =C2=A0 state =3D hash_value(state, value);</div=
><div>=C2=A0 =C2=A0 return __implementation_defined_extract_value(state);</=
div><div>=C2=A0 }</div><div>};</div><div><br></div><div>Or:<br></div><div><=
br></div><div>struct MyHashCode {</div><div>=C2=A0 ...</div><div>=C2=A0priv=
ate:</div><div>=C2=A0 =C2=A0 ...</div><div>=C2=A0 =C2=A0 friend class MyHas=
h;</div><div>=C2=A0 =C2=A0 operator size_t() const;</div><div>};</div><div>=
<br></div><div>struct MyHash {</div><div>=C2=A0 template &lt;typename T&gt;=
</div><div>=C2=A0 size_t operator()(const T&amp; value) const {</div><div>=
=C2=A0 =C2=A0 MyHashCode state;</div><div>=C2=A0 =C2=A0 return hash_value(s=
tate, t);</div><div>=C2=A0 }</div><div>};</div><div><br></div><div>Essentia=
lly, the only part which remains undefined is the internal interface betwee=
n the top-level hash algorithm and its internal state.</div></div></div><di=
v dir=3D"ltr"><div class=3D"gmail_quote"><div><br></div><div>--Shahms</div>=
</div></div><div dir=3D"ltr"><div class=3D"gmail_quote"><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535=
8<br>
<br>
--<br>
<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 <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote></div></div></blockquote></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&quot; 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 />

--001a1143a3e824104905215ef3e9--

.

On Mon, Oct 5, 2015 at 10:34 AM, Shahms King <shahms.king@gmail.com> wrote:
> 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.

Gotcha. In that case, this proposal is less complete than N3980 was.
The HashAlgorithm uhash<> interfaces were more widely usable. With
P0029, users have to write extraneous high-level wrappers around their
algorithms (a std::hash replacement), and generic code that needs to
support generic progressive hashes is left without a solution.

It seems to me a near trivial addition to require HashCode to have a
result_type and a conversion operator/method to result_type. It will
still satisfy all the goals of P0029 while also satisfy requirements
covered by N3980, no?

Is there a significant cost/risk of adding such an interface to the
HashCode concept?

--
Sean Middleditch
http://seanmiddleditch.com

--

---
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/.

.

On Monday 05 October 2015 17:34:04 Shahms King wrote:
> 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 <typename T>
> 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);
>   }
> };

If by __implementation_defined_init(), you mean the way I will initialise the
hash from my hash seed, I understand. But what constructors and assignment
operators will std::hash_code have so I can create it from my hash seed?

As for the extract value, I don't get it.

Can you give as example the two most trivial implementations? That is, the one
where there's no extra state before or after the hashing of the value type (no
seed) and the one where the seed is just a global integer value initialised
from a random source.

--
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/.

.

--001a113d9f7a0f81e50521631c8d
Content-Type: text/plain; charset=UTF-8

As far as I understand it, you don't.  std::hash_code is the internal state
of whatever hash algorithm is being used by std::hash.  Either you're using
std::hash, in which case it initializes the std::hash_code through
mechanisms unknown and similarly extracts the value or you're using a
different algorithm which uses a different type to represent its internal
state which conforms to the HashCode concept and you don't traffic in
std::hash_code at all.  At least, that's my reading of the proposal.

Either your hash_value() function accepts std::hash_code and only works
with std::hash, or it's a template and supports any conforming hashing
algorithm.

--Shahms

On Mon, Oct 5, 2015 at 1:58 PM Thiago Macieira <thiago@macieira.org> wrote:

> On Monday 05 October 2015 17:34:04 Shahms King wrote:
> > 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 <typename T>
> > 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);
> >   }
> > };
>
> If by __implementation_defined_init(), you mean the way I will initialise
> the
> hash from my hash seed, I understand. But what constructors and assignment
> operators will std::hash_code have so I can create it from my hash seed?
>
> As for the extract value, I don't get it.
>
> Can you give as example the two most trivial implementations? That is, the
> one
> where there's no extra state before or after the hashing of the value type
> (no
> seed) and the one where the seed is just a global integer value initialised
> from a random source.
>
> --
> 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/.

--001a113d9f7a0f81e50521631c8d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">As far as I understand it, you don&#39;t. =C2=A0std::hash_=
code is the internal state of whatever hash algorithm is being used by std:=
:hash.=C2=A0 Either you&#39;re using std::hash, in which case it initialize=
s the std::hash_code through mechanisms unknown and similarly extracts the =
value or you&#39;re using a different algorithm which uses a different type=
 to represent its internal state which conforms to the HashCode concept and=
 you don&#39;t traffic in std::hash_code at all.=C2=A0 At least, that&#39;s=
 my reading of the proposal.<div><br></div><div>Either your hash_value() fu=
nction accepts std::hash_code and only works with std::hash, or it&#39;s a =
template and supports any conforming hashing algorithm.<div><br></div><div>=
--Shahms</div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">O=
n Mon, Oct 5, 2015 at 1:58 PM Thiago Macieira &lt;<a href=3D"mailto:thiago@=
macieira.org">thiago@macieira.org</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">On Monday 05 October 2015 17:34:04 Shahms King wrote:<br>
&gt; You can trivially use them in your own hashing container, as you would=
<br>
&gt; now.=C2=A0 The primary thing that is being changed is the mechanism by=
 which<br>
&gt; user-defined types can supply their data to the hash function, not the=
<br>
&gt; interface for retrieving final values from that hash function.=C2=A0 T=
he<br>
&gt; high-level API for retrieving a hash value from an object is unchanged=
, e.g.<br>
&gt;<br>
&gt; template &lt;typename T&gt;<br>
&gt; struct hash {<br>
&gt;=C2=A0 =C2=A0size_t operator() (const T&amp; value) const {<br>
&gt;=C2=A0 =C2=A0 =C2=A0std::hash_code state =3D __implementation_defined_i=
nit();<br>
&gt;=C2=A0 =C2=A0 =C2=A0state =3D hash_value(state, value);<br>
&gt;=C2=A0 =C2=A0 =C2=A0return __implementation_defined_extract_value(state=
);<br>
&gt;=C2=A0 =C2=A0}<br>
&gt; };<br>
<br>
If by __implementation_defined_init(), you mean the way I will initialise t=
he<br>
hash from my hash seed, I understand. But what constructors and assignment<=
br>
operators will std::hash_code have so I can create it from my hash seed?<br=
>
<br>
As for the extract value, I don&#39;t get it.<br>
<br>
Can you give as example the two most trivial implementations? That is, the =
one<br>
where there&#39;s no extra state before or after the hashing of the value t=
ype (no<br>
seed) and the one where the seed is just a global integer value initialised=
<br>
from a random source.<br>
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535=
8<br>
<br>
--<br>
<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 <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br />
<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 <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 />

--001a113d9f7a0f81e50521631c8d--

.

On Monday 05 October 2015 22:33:50 Shahms King wrote:
> As far as I understand it, you don't.  std::hash_code is the internal state
> of whatever hash algorithm is being used by std::hash.  Either you're using
> std::hash, in which case it initializes the std::hash_code through
> mechanisms unknown and similarly extracts the value or you're using a
> different algorithm which uses a different type to represent its internal
> state which conforms to the HashCode concept and you don't traffic in
> std::hash_code at all.  At least, that's my reading of the proposal.
>
> Either your hash_value() function accepts std::hash_code and only works
> with std::hash, or it's a template and supports any conforming hashing
> algorithm.

Ok, so the class is not useful or interesting at all for me. I will pay it no
further attention.

--
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/.

.