On Sun, 08 Jan 2012 08:40:27 -0500, Jonathan M Davis <[email protected]>
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
