getNext

Mehrdad wfunction at hotmail.com
Mon Jul 9 12:46:41 PDT 2012


On Monday, 9 July 2012 at 19:30:25 UTC, Jonathan M Davis wrote:
> Except that how output ranges are written to and an input range 
> with assignable elements are fundamentally different. Output 
> ranges use put, which _might_ write to each individual element, 
> or it may just append to the output range (it all depends on 
> the implementation of put). You're essentially generating a 
> range when you use an output range. But with an  input range 
> with assignable elements, you're specifically setting each 
> element in an existing range rather than generating a new one. 
> You can think of an output range like an output stream, whereas 
> an input range with assignable elements is like an array where 
> you're assigning values to each of its elements.

Oh!! So they're _exactly_ emulating C++ here, with 
insert_iterators trying to mimic regular iterators and all. I 
_never_ got that impression from the docs.
The impression the docs give is that the only time when you "add" 
instead of "overwrite" is when it either doesn't make sense to 
overwrite (e.g. into hash set, at the end of an array, etc.).
They never implied that you you might also be inserting into 
somewhere where overwriting is possible, so clearly I 
misunderstood what was intended.


Btw, I just realized:

With that explanation, hasAssignableElements doesn't make sense 
for some things that it should make sense for.

How do you "assign" to e.g. a range of a BST? It _certainly_ 
makes sense to do a transform() on it, but assigning to any 
particular element doesn't make sense. So I think that confirms 
that what we really want IS an I/O range -- a range that supports 
delete-modify-add, but not (necessarily) read-modify-write (which 
is what hasAssignableElements implies).

Makes sense?


More information about the Digitalmars-d mailing list