Closed mikekaganski closed 9 months ago
Mmmmh I think this pre-dates support for transparent comparison as implemented in https://github.com/serge-sans-paille/frozen/pull/124 so I should probably just remove these API in favor of transparent comparator. @nbrachet can you confirm?
There are versions of
unordered_map
'sat
andfind
in thepublic
section, taking a hasher and a comparator. How are they intended to be used?Say, I want to provide non-default (i.e., not used for the container ctor) values there. A specific example: a map of a string to something, constructed with a case-sensitive comparator and hasher. I want to use a case-insensitive comparator and hasher in a
find
call site, realizing it would incur run-time penalty (OK), but what I would get would be not-found result: thefind
would usefind_impl
; the latter would uselookup
, thenlookup_impl
, thenbits::pmh_tables::lookup
; and finally, that function would look up what the hasher generated, in thefirst_table_
, where the elements were put using the original hasher - so it would likely return a wrong entry, or no entry at all. Then back inunordered_map::at
orfind
, the returned result's key will be compared with the passed key, using the passed comparator - and indeed, since what was found was junk, it will not match.Are there good uses of these APIs? Possibly what I wanted to implement (and what I presently implemented using simple loop over items of the map) may be done using smart choice of the hasher passed there - then could you please provide guidelines how to create such a hasher?
Thank you!