From: Peter Simons (simons_at_[hidden])
Date: 2005-04-22 09:24:09
Iain Hanson writes:
>>> This would give a significant performance hit as there
>>> will now be two copies of the data.
>> Not if the callback doesn't make any copies.
> That is a long way from being the common case.
Maybe, maybe not. My point is that whether or not data has
to be copied depends on the _callback_, not on the I/O
driver. Your original statement made it appear as if copying
of data would be inevitable in a callback-driven design --
and it is not.
> I really don't see this as workable in the general case.
> The library has to guess the size of the read buffer.
No, the caller can provide the capacity (or the buffer).
> It would also prevent reading a complete record on a
> stream by reading a header up to the length field and
> then making a 2nd read call for that length with the
> correct size buffer.
Why exactly would that be impossible in a callback-driven
> It would also add dynamic memory allocation to the
> library [...].
Let the user pass the buffer when calling the driver, and
then there's no memory management at all.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk