Boost logo

Boost :

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, gregod at, cpdaniel at, john at