buffered input

[spir]

On 02/07/2011 02:01 PM, Steven Schveighoffer wrote:
> On Sat, 05 Feb 2011 10:02:47 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> On 2/5/11 2:45 AM, Michel Fortin wrote:
>>> One thing I'm wondering is whether it'd be more efficient if we could
>>> provide our own buffer to be filled. In cases where you want to preserve
>>> the data, this could let you avoid double-copying: first copy in the
>>> temporary buffer and then at the permanent storage location. If you need
>>> the data only temporarily however providing your buffer to be filled
>>> might be less efficient for a range that can't avoid copying to the
>>> temporary buffer for some reason..
>>
>> 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.
>
> I may want to store 1% of a very large file. You are saying I must either a)
> unbuffer the entire file (handling the buffering on my own) or b) take the
> penalty and double copy the data.
>
> I want c) temporarily use my buffer for buffering until I say to stop.
>
> The range interface doesn't make this easy...

This looks very similar to a possible current use case of mine. (lookahead on 
demand --> possible backtracking)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com