RFC on range design for D2

Steven Schveighoffer schveiguy at yahoo.com
Tue Sep 9 13:08:30 PDT 2008


"Andrei Alexandrescu" wrote
<snip>

Excellent ideas!  I think the best part is about how you almost never need 
individual iterators, only ever ranges.  Perfectly explained!

One issue that you might not have considered is using a container as a data 
structure, and not using it for algorithms.  For example, how would one 
specify that one wants to remove a specific element, not a range of 
elements.  Having a construct that points to a specific element but not any 
specific end element might be a requirement for non-algorithmic reasons.

Also, some ranges might become invalid later on whereas the iterators would 
not.  Take for example a Hash container.  If you have to rehash the table, a 
range now might not make any sense, as the 'end' element may have moved to 
be before the 'begin' element.  But an iterator that points to a given 
element will still be valid (and could be used for removal).  In fact, I 
don't think ranges make a lot of sense for things like Hash where there 
isn't any defined order.  But you still should have a 'pointer' type to 
support O(1) removal.

One doesn't see any of these problems with arrays, because with arrays, you 
are guaranteed to have contiguous memory.

What I'm trying to say is there may be a reason to have pointers for certain 
containers, even though they might be unsafe.

My personal pet peeve of many container implementations is not being able to 
remove elements from a container while iterating.  For example, I have a 
linked list of open file descriptors, iterate over the list, closing and 
removing those that are done (which should be O(1) per removal).  In many 
container implementations, iteration implies immutable, which means you have 
to add references to the elements to remove to another list to then remove 
afterwards (somtimes at the cost of O(n) per removal.  grrrr.)  I hope 
ranges will support removal while traversing.

That's all I have for now, I have to go think about how this will impact 
dcollections :)

-Steve 




More information about the Digitalmars-d-announce mailing list