can't use the same type for the hasher and the equal key

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a struct along these lines:
struct VertInfo {
    uint32_t vidx;
    uint32_t tidx;

    VertInfo() : vidx(0xffffffff), tidx(0xffffffff) {}
    VertInfo(uint32_t v, uint32_t t) : vidx(v), tidx(t) {}

    inline size_t operator() (const VertInfo &v) const {
        return (size_t)(vidx+1) + (size_t)(tidx+1);
    }

    inline bool operator () (const VertInfo &v0, const VertInfo &v1) const {
        return (v0.vidx == v1.vidx) & (v0.tidx == v1.tidx);
    } 
};

2. try to make a dense_hash_set like this:
typedef google::dense_hash_set<VertInfo, VertInfo, VertInfo> VertSet;
3. See the code not compile

What is the expected output? What do you see instead?
I expect this code to compile.

/home/budgeb/p4/pseb/RapidRT_PR/../external/thirdparty/google/sparsehash/1.7/inc
lude/google/sparsehash/densehashtable.h:1178:
error: duplicate base type ‘rapidpr::geom::VertInfo’ invalid

/home/budgeb/p4/pseb/RapidRT_PR/../external/thirdparty/google/sparsehash/1.7/inc
lude/google/sparsehash/densehashtable.h:1180:
error: multiple initializations given for base ‘rapidpr::geom::VertInfo’

What version of the product are you using? On what operating system?
1.7 on Linux64 with gcc 4.4

Please provide any additional information below.

I've looked at the code in densehashtable, and the problem is the Settings
class which inherits from both the hasher and the equal_key.  Of course if
they are the same, it tries to inherit from the same type twice, which is
apparently not allowed.

Of a certainty, the workaround(s) are easier than a true fix, however, it
would be great to have this working in general.

Original issue reported on code.google.com by brian.budge@gmail.com on 2 Apr 2010 at 11:36

[GoogleCodeExporter]

Ha, though, this compile error actually led me to fix a bug in my code that has 
been
there quite a while :)... the hash isn't using the v that is passed in. 

Original comment by brian.budge@gmail.com on 2 Apr 2010 at 11:40

[GoogleCodeExporter]

Heh!  We actually had identified this regression in the hashtable code before 
the
release, and decided that probably nobody did that.  Shows what we know -- 
everything
happens on the internets somewhere.

The best solution, in the short term, is to separate out the hasher and 
equal_key
into two classes (or to go back to using sparsehash 1.6).  We'll try to figure 
out a
longer-term solution.  Sorry for the trouble.

Original comment by csilv...@gmail.com on 3 Apr 2010 at 1:21

• Changed state: Accepted
• Added labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

Glad it will be fixed, if possible.  My workaround was just as you describe, 
and of
course it works fine now.

Thanks.

Original comment by brian.budge@gmail.com on 5 Apr 2010 at 3:35

[GoogleCodeExporter]

We found a different way to pack these that gives the same space advantage 
without 
causing the conflict you saw.  This will be in the next release.

Original comment by csilv...@gmail.com on 5 Apr 2010 at 6:55

• Changed state: Started

[GoogleCodeExporter]

This should be fixed in sparsehash 1.8, just released.

Original comment by csilv...@gmail.com on 29 Jul 2010 at 9:52

• Changed state: Fixed