On Mon, 09 Jan 2012 13:35:26 -0500, Andrej Mitrovic <andrej.mitrov...@gmail.com> wrote:

On 1/9/12, Steven Schveighoffer <schvei...@yahoo.com> wrote:
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).

Funny, I was looking at the docs a few days ago and it said "Adding an
element can invalidate cursors depending on the implementation.", so I
just assumed it did invalidate the cursors.

Yeah, I could have sworn I stated somewhere that the current implementation doesn't invalidate cursors, but apparently it's not stated. I think the docs need a lot of TLC before the first release. Some day when I have time...

To clarify what I plan to do, the add doc will say something like "adding an element can invalidate cursors depending on the implementation, however the default implementation guarantees not to invalidate them." I don't want to specifically disallow implementations which do invalidate (dcollections' implementations are pluggable so anyone can replace the internals).

I do think those are dcollections v1 docs though. Anyway glad to hear
from you about this.

The D2 docs are somewhat leftover from D1 version. However, I do remember when implementing the hash code that it purposely does not invalidate cursors on a rehash. Ranges can be invalidated, however. Given the implementation, it's actually faster *not* to invalidate them when rehashing because I just relink all the link-list nodes instead of reallocating them.

-Steve

Reply via email to