buffered input

spir denis.spir at gmail.com
Sat Feb 5 03:46:22 PST 2011


On 02/05/2011 10:36 AM, Nick Sabalausky wrote:
> On a separate note, I think a good way of testing the design (and end up
> getting something useful anyway) would be to try to use it to create a range
> that's automatically-buffered in a more traditional way. Ie, Given any input
> range 'myRange', "buffered(myRange, 2048)" (or something like that) would
> wrap it in a new input range that automatically buffers the next 2048
> elements (asynchronously?) whenever its internal buffer is exhausted. Or
> something like that. It's late and I'm tired and I can't think anymore ;)

That's exactly what I'm expecting.
Funnily enough, I was about to start a thread on the topic after reading 
related posts. My point was:
"I'm not a specialist in efficiency (rather the opposite), I just know there is 
--theoretically-- relevant performance loss to expect from unbuffered input in 
various cases. Could we define a generic input-buffering primitive allowing 
people to benefit from others' competence? Just like Appender."

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



More information about the Digitalmars-d mailing list