associative arrays

[Steven Schveighoffer]

On Sun, 08 Jan 2012 08:40:27 -0500, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> On Sunday, January 08, 2012 14:24:32 simendsjo wrote:
>> Thanks for your clarifications.
>>
>> Does this mean even this is undefined?
>> aa["a"] = new C();
>> auto c = "a" in aa;
>> aa["b"] = new C();
>> // Using c here is undefined as an element was added to aa
>
> Yes. Depending on the current implementation of AAs and the state of aa  
> when
> "b" is added to it, c could still point to exactly what it did before,  
> or aa
> could have been rehashed, which could move any or all of its elements  
> around,
> in which case who knows what c points to.

Actually, not invalid for the current implementation.  I don't know if  
it's stated whether an AA specifically requires that elements do not  
re-associate on a rehash.

There are certain hash implementations (such as ones that involve a single  
array), which would invalidate pointers on a rehash.  So there is the  
potential (if it's not a stated requirement to the contrary in the spec)  
that some future AA implementation would invalidated references.  However,  
I'd say it's unlikely this would happen.

BTW, dcollections' HashMap, HashSet, and HashMultiset do guarantee that  
adding elements does not invalidated cursors (dcollections' safe version  
of pointers) as long as you use the default Hash implementation.  However,  
I just noticed this is not stated anywhere in the docs (will fix).



-Steve