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