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