serge-sans-paille / frozen

a header-only, constexpr alternative to gperf for C++14 users
Apache License 2.0
1.27k stars 103 forks source link

What are extended versions of `unordered_map::find`/`at` are for? #157

Closed mikekaganski closed 9 months ago

mikekaganski commented 1 year ago

There are versions of unordered_map's at and find in the public 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: the find would use find_impl; the latter would use lookup, then lookup_impl, then bits::pmh_tables::lookup; and finally, that function would look up what the hasher generated, in the first_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 in unordered_map::at or find, 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!

serge-sans-paille commented 11 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?