safe unordered local iterators

[François Dumont]

Thanks for you feedback

I agree with you Paolo that safe local iterators won't be as useful as 
normal ones but even so invalid iterator usage are so difficult to track 
that it still worth the effort.

The cost to introduce this tracking is equivalent to the one used to 
track usual iterators. On the unordered containers we need 2 additionnal 
pointers for the const and not-const local iterators. I also fear to 
have to add additional research in erase method, but I finally realized 
that transforming normal iterators in local ones was straightforward. It 
is done in the _S_to_local static methods that I have added to each 
unordered containers, this is surely the methods that will be impacted 
if normal data model is modified in the future. I don't think we need to 
use a special mode to activate it.

The libstdc++/41975 issue is interesting, I remember having a similar 
one when working on STLport for which I had rewritten the hash 
containers. I will check if the modif I had done to fix it can also be 
applied on libstdc++ implementation.

Regards


On 07/11/2011 12:13 PM, Paolo Carlini wrote:
>  Hi,
>> Yes, if it's possible for users to invalidate and misuse those 
>> iterators then it's a good idea to have debug mode checks. 
> Indeed. But my rough feeling would be that such misuses are much less 
> frequent and relevant than the other, with normal iterators. Francois, 
> can you provide a breakdown about the cost of tracking those local 
> iterators too? In terms of memory use, maybe performance too? We could 
> even imagine tracking those only in pedantic-mode or when an 
> additional macro is set, in case.
>
> By the way, talking about fixing the ABI, etc, we have definitely at 
> least a serious issue to resolve in the normal-mode unordered 
> containers, that is LWG 579 (aka libstdc++/41975), it's in my to do 
> list for 4.7.0, I'm not sure whether something will change in the 
> details of the local iterators which would impact the debug-mode 
> version too..
>
> Paolo.
>