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

Handling overloads for types which extend STL containers #3

Open
wavefunction91 opened this issue Apr 30, 2021 · 3 comments
Open

Handling overloads for types which extend STL containers #3

wavefunction91 opened this issue Apr 30, 2021 · 3 comments

Comments

@wavefunction91
Copy link

Currently, defining a custom hasher for types which extent STL containers (e.g. std::vector) lead to an ambiguous overload in hash_single_ delegating between the user defined hash implementation and the free-standing hash_object defined for its STL instantiation.

e.g.

struct A {
  int x;
  void hash( bphash::Hasher& h ) const { h( x ); }
};

struct B : public std::vector<A> {
  double y;
  void hash( bphash::Hasher& h ) const { 
    h( dynamic_cast<const std::vector<A>&>(*this), y ); 
  }
};

Generally, the delegation to B::hash and hash_object( const std::vector<A>& ) is ambiguous in the delegation for hash_single_

Without knowing for sure your motivations, my guess is that you would want to prefer the user defined hash (B::hash in this case) rather than the hash_object implementation.

I have a fix for this which SFINAE disables the hash_object path when the member function implementation exists. I'm more than happy to PR it, but it depends on #2 (this was done in the context of NWX which pulls that PR). let me know how you'd like to proceed or if you have other opinions on the preference to resolve the ambiguous function call.

@ryanmrichard
Copy link

It's tangent to the actual issue, and you may already be aware, but you need to be very careful publicly inheriting from STL containers. The dtors are not virtual; so you'll run into all sorts of problems if you attempt to use the classes in typical polymorphic scenarios (i.e., passing the objects around via the base class).

@wavefunction91
Copy link
Author

wavefunction91 commented May 2, 2021 via email

@ryanmrichard
Copy link

FWIW, I don't think @bennybp wants to support this library anymore so it may be time to look into another hashing library or to have him give one of us admin privileges on this repo so we can improve it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants