On 2/6/11 10:59 PM, Robert Jacques wrote:
On Sun, 06 Feb 2011 21:47:48 -0500, Torarin <torar...@gmail.com> wrote:
2011/2/7 Robert Jacques <sandf...@jhu.edu>:
On Sun, 06 Feb 2011 10:43:47 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 2/6/11 6:01 EST, Tomek Sowiński wrote:
Nick Sabalausky napisał:
discard and fetch?
I like that.
What's missing is the part that they refer to front. Maybe
discardFromFront() and fetchToFront()? But then I like
discardFromFront()
and appendToFront() better - the latter is about as long and more
informative.
Don't forget that these are relatively rarely used.
Andrei
Actually, I don't think these functions would be relatively rarely
used. I
don't see that many people using a buffered input's popFront. Instead
I see
shiftFront in its place and an appendToFront call has to be made
whenever
buffer.front.empty.
Why not popFront if empty?
Because even reading UTF-8 requires more than 1-byte of information.
Basically, any routine that processes a raw stream is going to have to
handle the case where what they're processing straddles the buffer
boundary. Now, if the routine wraps the raw stream in some higher-order
range, such as byLine, which guarantees them that none of their inputs
straddle, great. But it would be negligent to neglect those coders
writing the higher-level ranges.
They aren't being neglected. If you need to get more stuff in the
current unit of work, use appendToFront().
Let's restart this. What do you want to do that you can't do with the
proposed API?
Andrei
