On 5/30/16 8:44 AM, Andrei Alexandrescu wrote:
On 05/30/2016 08:21 AM, Joseph Rushton Wakeling wrote:
On Sunday, 29 May 2016 at 17:29:35 UTC, Steven Schveighoffer wrote:
This doesn't help at all. I can still make a "transient" range with
all three range primitives.
There seems to be a misunderstanding about what a transient range is.
byLine is a transient range that requires the front element be
cacheable (I have to build the line somewhere, and reusing that buffer
provides performance). Shoehorning into a popFront-only style "range"
does not solve the problem. Not only that, but now I would have to
cache BOTH the front element and the next one.
Ack, yea, I think see the issue. It's
auto a = transientRange.front;
transientRange.popFront() // <=== now a has changed
Even if you go with the only-2-primitives one, you'd have the same
problem:
auto a = transientRange.front;
auto b = transientRange.front; // <=== now a has changed
That's right. The one approach that works here is to acknowledge the
range has no buffering at all and require the user to provide the buffer
as an argument. However, that would make for a different primitive that
does not fit within the range hierarchy. -- Andrei
Yes, this is how e.g. Linux getline works. But this leaks even more
implementation details to the user, and still doesn't solve the problem,
it just pushes it onto the user.
It also would make for some awkward pipelining.
Another solution is to accept a "buffer manager" that is responsible for
determining how to handle the buffering.
-Steve
