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
design?
> 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.
Peter