On Friday, 28 March 2014 at 04:58:28 UTC, Walter Bright wrote:
On 3/27/2014 3:21 AM, Chris wrote:
I agree. I've been using ranges for a while now and have tried
different implementations based on advice given on this forum
and
depending on each case. After reading this thread I looked at
some of my ranges and I have to say I still have no clue as to
what should and should _not_ be done (regardless of whether you
_can_ do it). For a while I thought that it's my lack of
understanding, but this thread shows that everyone has a
different view of ranges. Guidelines with use cases would be
great. I remember I mentioned this in another thread already.
The
thing is that experimenting without proper guidelines leaves
your
code in an inconsistent state where you have two or more ranges
doing technically the same thing but each with a different
logic.
Following the protocol empty-front-popFront always works.
Where the differences come in is when people skip calling empty.
Not only there. The whole issue of front and popFront has not
been made clear yet (unless it's my lack of understanding). What
should and should not be done there, even if you stick to the
basic protocol (!empty > front > popFront).
I like the concept of ranges and use them a lot, because they
help me to create independent components. But sometimes I think
they are just glorified for-loops in the sense that we know more
or less what the input is, and part of the reason why we have
this thread is that we want everything to be specialized and
generic at the same time. E.g.
@monarch_dodra wrote:
"It's not that *you* know a particular range doesn't need "empty"
called, it's that the algorithm you are using has already
previously validated there are elements in it.
For example, the splitter algorithm will first save a copy of its
range, and then walk it, searching for the "splitting" elements.
It then realizes it has walked N elements."
But then it's no longer generic. If your range depends on another
algorithm (that you assume or know to have checked something),
then it's no longer generic. In many cases "generic" means an
overhead of checks, and is anathema to performance tuning. I
think it's the issue of generic vs. specialized / optimized that
started this thread. And this is a tough one to sort out.
