On 02/07/2011 02:01 PM, Steven Schveighoffer wrote:
On Sat, 05 Feb 2011 10:02:47 -0500, Andrei Alexandrescu
<seewebsiteforem...@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
