Creating a Sub-view of a non - RA (hasSlicing) range.
monarch_dodra
monarch_dodra at gmail.com
Sun Jul 1 06:22:16 PDT 2012
On Saturday, 30 June 2012 at 23:51:42 UTC, Andrei Alexandrescu
wrote:
> Yes. But now you're moving the goalposts because many of your
> arguments referred to SList.
I'm sorry, that's not what I meant to do. The goal post was not
moved, rather misplaced to begin with. Using SList for making my
point was not the best choice of containers. I'd hae used a
"DList" like container if I had one.
On Saturday, 30 June 2012 at 23:51:42 UTC, Andrei Alexandrescu
wrote:
> Correct. take() and takeExactly() work under the assumption
> there's no surreptitious change in the structure of the range
> underneath. I think that's a reasonable decision.
Most of the time yes. But for certain "partitioning" algorithms,
those that _cut_ a range into several subranges (for example
"findSplit"), such "surreptitious" change should (IMO) be
expected and supported.
On Saturday, 30 June 2012 at 23:51:42 UTC, Andrei Alexandrescu
wrote:
> Which is as it should be. How would you otherwise take the
> first n elements of a given doubly-linked list in constant time?
Constanst time, I don't know. I'm still looking for a way to do
it in o(N) ;)
On Saturday, 30 June 2012 at 23:51:42 UTC, Andrei Alexandrescu
wrote:
> It's all about what it takes to reach a certain point. You are
> sensing something indeed, but take() is not it. The problem is
> there's no simple way to count 5 starting from the left side of
> a doubly-linked list, stop there, and then create a range from
> the beginning of the list and that mid point. In C++, that's
> trivial because range ends are separate.
>
>> ----
>> I came to D after reading your talk on ranges, and I really
>> liked (and
>> am still enjoying) the concept. However, with C++, when you
>> iterate over
>> [First, Last), you are also creating a two new ranges: [First,
>> Current)
>> & [Current, Last). D doesn't provide that, it only provides a
>> way to
>> shrink the current range and create [Current, Last).
>
> Yes, that's a good way of putting it.
>
>> Using range, you don't get [First, Current). At best, you only
>> get
>> a)A forward range only
>> b)A fixed size range
>> c)A range of another type
>
> We could extend the range interface for specific ranges to
> allow for such. However, there hasn't been a strong need so far.
>
>
> Andrei
Thanks again for your replies. I'm really enjoying using D and
ranges, and I get that nothing is "free", and this issue is one
of the by products of moving from iterators-pairs to more
powerful, but restrictive, ranges.
I get the "no sense in making things more complicated if there is
not a strong need", but at the same time, I've always felt that a
language's algorithm facility should always we imaculate. Further
more, it really feels as if the interface is just one concept shy
of being able to make something like this work...
Something like...
"inverseRangeBegin(R big, R small)": Creates a range that begins
where big starts, and ends where small starts. R must be at least
bidirectional. small must be included inside big.
From an implementation point of view, I think any container, and
even arrays, can do it. I pretty sure this is compeltly feasable.
Just off the top of my head. I'm sure there are brighter thinkers
out there that have put more thought into it.
More information about the Digitalmars-d
mailing list