Failed to sort range

Ali Çehreli acehreli at yahoo.com
Tue May 28 11:31:00 PDT 2013


On 05/28/2013 11:19 AM, Sergei Nosov wrote:

 > Do you mean it's a good idea
 > to separate storage and access (via range) to the container? Like
 > std.container's containers (heh) have nested Range struct?

Yes, that is generally the right approach. Note that built-in arrays 
have a similar design which may not be obvious: The storage is in an 
array that is owned by the D runtime. (The exception is fixed-length 
arrays where the entire array may be on the stack.)

Then, the elements are accessed by slices, which are ranges. Consuming 
the slice does not invalidate the consumed elements (as long as there 
are other accesses to those elements.)

 >>     ref T opIndex(size_t idx) {
 >>         return vec_[front_ + idx];
 >>     }
 >>
 >> It is a start but still not the solution. Sorry... :/
 >
 > That's obviously a bug, thanks. But, yeah, not the last one =)

     @property Array!T opSlice(size_t i, size_t j) {
         // ...
         ret.front_ = i;

I feel like the initialization of front_ above is not right either. 
Imagine quick sort where we are slicing the right-hand side of a range 
as [0..10], which has already been sliced before. Setting front_ to 0 
would be wrong because then opIndex would still be counting from the 
beginning of the original elements.

Ali



More information about the Digitalmars-d-learn mailing list