Hello all,
In the TR1 unordered set proposal it seem there is no direct way for
the user to enforce max number of buckets.
I think this ability to control the max number of buckets (and
therefore control if there will be rehashing) is sometime desirable.

For example - if the hashing function generate for all keys a value in
finite range [0-R) then adding buckets will not work. In fact in this
case the hash table with trash all the time adding more and more
buckets while the buckets [R-bucket_count()) remain empty.
This will happen if the hash function has a mapping to a limited range
or if the keys are of limited range and the hash function does not
spread the keys enough.
In some cases this is ok - especially when the buckets have some
external meaning that is unknown from the container. (This is probably
also when the local_iterators are most useful).

I would suggest that max_load_factor(z) with z=0 will force no resize.

Another topic - some time it is useful to change the hashing function
on the fly. The reason is that the quality of the hash function
depends heavily on the keys. It is hard to create a good hash function
for every circumstance. While it is possible to simply generate a new
hash table it is probably better to allow rehashing with a new hashing
function.


What do you think?

Sharon

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]