Assertion failed: num_probes < bucket_count(),

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Compiling this :

#include "dense_hash_set"

struct s_s
{
    unsigned int ui;
    unsigned char uc;
};

size_t hash_value(const s_s * s)
{
    return s->ui ^ s->uc;
}

bool operator<(const s_s & lhs, const s_s & rhs)
{
  return lhs.ui < rhs.ui;
}

struct eqstr
{
bool operator()(const s_s * s1, const s_s* s2) const
{
    return 0;
}
};

int main() 
{ 
stdext::hash_set<s_s*, stdext::hash_compare<s_s*, std::less<s_s*>>> hz;

s_s z;
h[&z]=1;
hz.insert(&z);
hz.find(&z);

google::dense_hash_set<s_s*,stdext::hash_compare<s_s*,std::less<s_s*>>,eqstr >
hzz;
    hzz.set_empty_key(0);
    hzz.insert(&z);
    //hzz.find(&z);

    return 1;

2.
3.

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?
visual studio 2005

Please provide any additional information below.
It seems that the hash_set from microsoft is working well but i got an
assertion from the google hash_set.

Moreover, i've got a question about hash_map(set), when using find, we need
to create an object to hash it and then search? So we can create new object
that are already in the set?

As my object are unique, but i haven't a unique id to check if the object
exist already, i need to do a find and add if unique. 
Does a multimap <int key,object*> would be more efficient if the key is
obtained by the same hashing function as used for hash_set, but in this
case we do not need to create an object? We would have the same number of
collision if the hashing function is the same? Am i right?
I know insertion is slower in map than hash.. but we have to create object
for hash_map. Can you give me an advice about performance choice for this case?
Thanks 
Laurent

Original issue reported on code.google.com by L.VanMiegroet on 26 Feb 2009 at 8:27

[GoogleCodeExporter]

Sorry, i found that eqstr should not be given in declaration of hash_set. It 
runs now

Original comment by L.VanMiegroet on 26 Feb 2009 at 8:50

[GoogleCodeExporter]

Original comment by csilv...@gmail.com on 26 Feb 2009 at 9:19

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