buffered input

[Michel Fortin]

On 2011-02-05 10:02:47 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> Generally when one says "I want the stream to copy data straight into 
> my buffers" this is the same as "I want the stream to be unbuffered". 
> So if you want to provide your own buffers to be filled, we need to 
> discuss refining the design of unbuffered input - for example by adding 
> an optional routine for bulk transfer to input ranges.

You're right, this is a different thing.

My major gripe with ranges at this time is that it's almost impossible 
to design an algorithm that can take slices *or* make copies depending 
on whether the range supports slicing or not, and whether the slices 
are stable (not going to be mutated when popping elements from the 
range). At least not without writing two implementations of it.

I reread your initial post to get a clearer idea of what it meant. It 
seems to me that your buffered range design could be made to fix that 
hole. If the data you want to parse is all in memory, the buffered 
range could simply use the original array as its buffer; shiftFront 
would simply just the whole array to remove the first n elements while 
appendToFront would do nothing (as the buffer already contains all of 
the content). And if the data is immutable, then it's safe to just take 
a slice of it to preserve it instead of doing a copy. So you can't 
really be more efficient than that, it's just great.

As for getting the data in bulk directly so you can avoid needless 
copies... I think the same optimization is possible with a buffered 
range. All you need is a buffered range that doesn't reuse the buffer, 
presumably one of immutable(T)[]. With it, you can slice at will 
without fear of the data being overwritten at a later time.

So my rereading of your proposal convinced me. Go ahead, I can't wait 
to use it. :-)

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/