On Thu, 14 Apr 2011 14:24:41 -0400, spir <denis.s...@gmail.com> wrote:
On 04/14/2011 06:57 PM, Andrej Mitrovic wrote:
This leads me to another question I've always wanted to ask. A call
such as:
auto b=map!foo(map!bar1(map!bar2(a));
This constructs a lazy range. What I'm wondering is if there are any
performance issues when constructing long chains of ranges like that,
since this basically routes one function to the next, which routes to
the next, etc. E.g:
auto a = [1, 2];
auto b = retro(a);
auto c = retro(b);
auto d = retro(c);
Under the surface, I assume calling d.front would mean the following
calls:
d.front()->c.back()->b.front()->a.back()
Or another example:
auto b = retro(retro(a));
Can the compiler optimize the second case and convert b.front to just
do one field access?
If it does optimise, then it is definitely a compiler bug. Since you
*explicitely* ask for a double reverse, it *must* just do it.
Suppressing them is here just breaking the language's semantics!
I feel like people aren't looking at my post :)
retro *specifically* returns the source range if you retro it again.
from std.range:
auto retro(Range)(Range r)
if (isBidirectionalRange!(Unqual!Range))
{
// Check for retro(retro(r)) and just return r in that case
static if (is(typeof(retro(r.source)) == Range))
{
return r.source;
}
...
-Steve
