On Thursday, 27 March 2014 at 15:45:14 UTC, Andrei Alexandrescu
wrote:
On 3/27/14, 8:44 AM, Steven Schveighoffer wrote:
On Thu, 27 Mar 2014 11:40:59 -0400, Andrei Alexandrescu
<[email protected]> wrote:
On 3/27/14, 5:35 AM, Steven Schveighoffer wrote:
BTW, I think there has been recent talk about not focusing
on dust when
we are laying bricks. This would have my vote as useless
dust. This does
not solve the problem of streams-as-ranges, because streams
don't make
good ranges. It doesn't really solve any problems as far as
I can tell.
I think byXchar are important and are not streams. -- Andrei
What's broken about those?
Speed.
I call shenanigans. This is the code:
@property bool empty()
{
if (nLeft)
return false;
if (r.empty)
return true;
If you initialized the next element in both constructor and
popFront, then you'd get rid of both these checks.
Furthermore, popFront() has a guaranteed "1 call" per element.
Weareas "empty" and "front" may be called several times in a row
for a single element.
If you want efficiency, stop being "member-wise" lazy, and put
some eagerness in your code.
filter comes to mind. -- Andrei
You *just* turned down a pull that did exactly that, for exactly
the same reasons.
Have "byXChar" function like filter: construction and popFront do
the work, and front/empty is 0(1), and const, and strongly pure
to boot. I *know* the compiler likes that in terms of speed.
