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.
