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