Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEA] Use heterogenous lookup instead of per-function key equal/hash #26

Closed
jrhemstad opened this issue Jul 24, 2020 · 1 comment
Closed
Labels
good first issue Good for newcomers type: feature request New feature request

Comments

@jrhemstad
Copy link
Collaborator

jrhemstad commented Jul 24, 2020

Is your feature request related to a problem? Please describe.

Sometimes we want to insert/find key types that may be different from the static_map::key_type. To support that today, we allow specifying a custom and independent key_equal and hash operations for insert and find. This is potentially quite problematic as it allows passing in different and conflicting notions of hashing and equality that could be incompatible and lead to undefined behavior.

  template <typename InputIt, typename Hash = MurmurHash3_32<key_type>,
            typename KeyEqual = thrust::equal_to<key_type>>
  void insert(InputIt first, InputIt last, Hash hash = Hash{},
              KeyEqual key_equal = KeyEqual{});

  template <typename InputIt, typename OutputIt,
            typename Hash = MurmurHash3_32<key_type>,
            typename KeyEqual = thrust::equal_to<key_type>>
  void find(InputIt first, InputIt last, OutputIt output_begin,
            Hash hash = Hash{}, KeyEqual key_equal = KeyEqual{}) noexcept

Describe the solution you'd like

A cleaner way to support the usecase of doing insert/find operations with different key types is via "heterogenous lookup".

In this way, the KeyEqual and Hash types would be specified only once as part of the static_map class template types, but it would allow those function's operators to be templates. This should require explicit user opt-in using the is_transparent trait.

#26 (comment)

@PointKernel
Copy link
Member

Solved during the grand refactoring

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers type: feature request New feature request
Projects
None yet
Development

No branches or pull requests

2 participants