getNext

Timon Gehr timon.gehr at gmx.ch
Mon Jul 9 12:54:01 PDT 2012


On 07/09/2012 09:52 PM, Timon Gehr wrote:
> On 07/09/2012 09:46 PM, Mehrdad wrote:
>> 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?
>
> struct BST(K){
>      struct Node{ ... }
>      Node root;
>      auto opSlice(){
>          struct Range{
>              ...
>              @property front(){ return ...; }
>              @property front(K k){
>                  deleteFront();
>                  root.add(k);
>              }
>          }
>      }
> }

(but BSTs do not actually support a range that implements transform.
Some elements might get transformed twice.)


More information about the Digitalmars-d mailing list