Iain Hanson wrote:
I really don't see this as workable in the general case. The library has to guess the size of the read 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.
This is a good point, but async_read can take a size parameter, even when the client does not supply a buffer.
It would also add dynamic memory allocation to the library
I'm not sure that you can beat the library from the client side with respect to the number of memory allocations. With N asynchronous reads active you need to keep N buffers alive. The library can manage with just one in the select case.
and be a source of runtime errors as a result a user not copying the buffer and trying to use it after its lifetime expired.
I'm fairly confident that manual buffer management will introduce even more runtime errors. ;-) (That's been my experience with async reads/writes, at least.)