Re: [boost] [asio] new version, prototype iostreams support

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2006-06-26 07:38:05

Hi Scott,

me22 <me22.ca_at_[hidden]> wrote:
> From http://asio.sourceforge.net/boost_asio_0_3_7/libs/
> asio/doc/examples/httpclient_sync_client_cpp.html
> :
>
>     boost::asio::streambuf request;
>     std::ostream request_stream(&request);
>     request_stream << "GET " << argv[2] << " HTTP/1.0\r\n";
>     request_stream << "Host: " << argv[1] << "\r\n";
>     request_stream << "Accept: */*\r\n";
>     request_stream << "Connection: close\r\n\r\n";
>
>     // Send the request.
>     boost::asio::write(socket, request);
>
> What advantage is the boost::asio::streambuf providing here?
> I don't see a different between it and just using a
> stringstream and sending the .str().

For writing data, the main advantage over stringstream (or
strstream) that I see is that data copying can be minimised.

I've tried to keep the interface such that internal buffers can
be allocated separately and chained deque-style. Using a chain
of buffers, data can be appended to the end or extracted from
the front without needing to copy around the existing contents.

However, if there's a single contiguous buffer then every time
the buffer is resized there's the possibility that all data in
the buffer would have to be copied to a new location.

Note that the current implementation of asio::streambuf does use
a contiguous buffer so I could implement it quickly :) So at the
moment this particular benefit isn't realised.

I don't know whether the standard permits a stringstream using
non-contiguous buffers. 27.7.1.3/8 at least seems to promote
using a single character array. However, even if it is
permitted...

Depending on your std::string and std::stringstream
implementation, you will probably incur an additional memory
allocation and data copy when you call .str() on the
stringstream to extract the contents. Calling asio::write() on
an asio::streambuf is guaranteed to write directly from the
internal buffers.

Cheers,
Chris