On 8/25/10 6:55 PDT, Peter Alexander wrote:
Thanks for the replies Andrei, Steven.
It's a bit disappointing that there is no solution to this,
although I think you already know what I'll suggest as a
solution :) (cursors/iterators)
It's quite funny really, because I had decided to drop the whole
iterator thing and just accept that the occassional small
performance/memory drop wasn't that big of an issue.
In order to try an appreciate ranges more I decided to try my hand
at writing a generic combinatorics library. Unfortunately, the
first function I tried to write (nextPermutation) requires exactly
[message was cut]
Peter --
Here's a thought. There are two possibilities I see to do this without
disrupting anything and without requiring everybody to implement a new
primitive.
1. Require random access for your nextPermutation. This is of course
imperfect, but something that we can live with. I do that in a couple of
places in Phobos.
2. Define a function like this:
R allBefore(R)(R all, R tail) if (isRandomAccessRange!R && hasLength!R)
{
// assume tail starts somewhere inside all and ends where all ends
enforce(all.length >= tail.length);
return all[0 .. all.length - tail.length);
}
R allBefore(R)(R all, R tail)
if (isBidirectionalRange!R &&
is(typeof(all.allBeforeImpl(tail)) : R))
{
return all.allBeforeImpl(tail);
}
Now in your code you can guard the definition of nextPermutation with
is(typeof(allBefore(r, r)). Then bidirectional ranges who want to
support nextPermutation will have to implement allBeforeImpl as a primitive.
I think we should do this for Phobos too.
Andrei