2011/2/7 Robert Jacques <sandf...@jhu.edu>: > 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. >
But popFront also reads more than 1 byte. Unless you call appendToFront with a larger value than the current buffer size, unless I have misunderstood, they should end up doing the same thing. Torarin