* Jonathan Wakely:
> On Thu, 13 Mar 2025 at 09:24, Florian Weimer <fwei...@redhat.com> wrote:
>>
>> * Jonathan Wakely:
>>
>> > On Thu, 13 Mar 2025 at 06:50, Florian Weimer <fwei...@redhat.com> wrote:
>> >>
>> >> * François Dumont:
>> >>
>> >> > + // Get hash code for a node that comes from another _Hashtable.
>> >> > + // Reuse a cached hash code if the hash function is stateless,
>> >> > + // otherwise recalculate it using our own hash function.
>> >> > + __hash_code
>> >> > + _M_hash_code_ext(const __node_value_type& __from) const
>> >> > + {
>> >> > + if constexpr (__and_<__hash_cached, is_empty<_Hash>>::value)
>> >> > + return __from._M_hash_code;
>> >> > + else
>> >> > + return this->_M_hash_code(_ExtractKey{}(__from._M_v()));
>> >> > + }
>> >>
>> >> Does C++ support stateful hash functions? I don't think so, and I don't
>> >> see it documented as a GNU extension, either.
>> >
>> > It does, yes. That's why the hash function isn't required to be
>> > default constructible, and has to be stored in the container and why
>> > doing swap on two containers has to swap the hash functions as well.
>>
>> Interesting. I have trouble reconciling this with the Cpp17Hash
>> requirement that “The value” h(k) “shall depend only on the argument k
>> for the duration of the program.”
>
>
> That's for a given value of the type, h. For any two values of the
> type h and h2, it's not required that h2(k) == h(k).
But the wording for the comp object for ordered containers is very
different and makes it clear that the instance matters.
I still think this is more confusing than necessary. If there isn't
some general rule that empty objects can be considered stateless, that
should be added somewhere, too. 8-)
Thanks,
Florian
