hashtable local iterator

[Paolo Carlini]

Hi,
> Hi
>
>     Since modification of hashtable implementation I was quite unhappy 
> of the impact on local_iterator and especially on the end(size_type 
> bkt) method that required to loop through all bucket nodes to access 
> the past-the-end one. This is why I would like to propose, if it is 
> still time, this new local iterator implementation that allow to 
> implement begin(size_t)/end(size_t) in constant time. Note that:
well, either we do this or, alternately, I'm afraid we have to revert 
the whole thing because the current behavior makes the new 
implementation non-conforming, right? Actually, in my opinion you should 
have pointed out the issue much more explicitly much earlier. If you are 
aware of similar issues, breaking the conformance of the implementation, 
please say it now, I would hate large last minute reversions.
> - this new iterator type needs a pointer to its parent container to 
> work which is quite unusual on normal iterators.
On the spot, I cannot see anything wrong with this. Normally, when such 
kinds of links are present one must be careful about what happens when 
one of the two changes without telling the other. Are we risking, I 
don't know, local iterators becoming invalid when they shouldn't?
> - I had to make an overload of _M_bucket_index public to use it in 
> local iterator implem', do you prefer to introduce a friend declaration ?
I guess friendship is much better.
>     Thanks to this new implementation I have been able to enhance 
> unordered container profile mode because it now relies on local 
> iterator. This way we can use most of the time the cached hash code 
> while with the current implementation the hash code must be recomputed 
> for each element in the container.
Ok, very good.

Thanks,
Paolo.