This change adds a new set of type requirements for dynamic buffers,
DynamicBuffer_v2, which supports copy construction. These new type
requirements enable dynamic buffers to be used as arguments to
user-defined composed operations, where the same dynamic buffer object
is used repeatedly for multiple underlying operations. For example:
template <typename DynamicBuffer>
void echo_line(tcp::socket& sock, DynamicBuffer buf)
{
n = boost::asio::read_until(sock, buf, '\n');
boost::asio::write(sock, buf, boost::asio::transfer_exactly(n));
}
The original DynamicBuffer type requirements have been renamed to
DynamicBuffer_v1.
New type traits is_dynamic_buffer_v1 and is_dynamic_buffer_v2 have been
added to test for conformance to DynamicBuffer_v1 and DynamicBuffer_v2
respectively. The existing is_dynamic_buffer trait has been retained and
delegates to is_dynamic_buffer_v1, unless BOOST_ASIO_NO_DYNAMIC_BUFFER_V1
is defined, in which case it delegates to is_dynamic_buffer_v2.
The dynamic_string_buffer and dynamic_vector buffer classes conform to
both DynamicBuffer_v1 and DynamicBuffer_v2 requirements.
When BOOST_ASIO_NO_DYNAMIC_BUFFER_V1 is defined, all support for
DynamicBuffer_v1 types and functions is #ifdef-ed out. Support for using
basic_streambuf with the read, async_read, read_until, async_read_until,
write, and async_write functions is also disabled as a consequence.
This change should have no impact on existing source code that simply
uses dynamic buffers in conjunction with asio's composed operations,
such as:
string data;
// ...
size_t n = boost::asio::read_until(my_socket
boost::asio::dynamic_buffer(data, MY_MAX),
'\n');
This change addresses an issue where a call to buffer_sequence_begin or
buffer_sequence_end could trigger an implicit conversion to const_buffer
or mutable_buffer. Whenever this implicit conversion occurred, the
return value of buffer_sequence_begin/end would point to a temporary
object.
The `async_result` template now supports a new form:
template <typename CompletionToken, typename Signature>
struct async_result
{
typedef /* ... */ return_type;
template <typename Initiation,
typename RawCompletionToken,
typename... Args>
static return_type initiate(
Initiation&& initiation,
RawCompletionToken&& token,
Args&&... args);
};
The `initiate()` function must:
* Transform the token into a completion handler object `handler`.
* Cause the invocation of the function object `initiation` as if
by calling:
std::forward<Initiation>(initiation)(
std::move(handler),
std::forward<Args>(args)...);
The invocation of `initiation` may be deferred (e.g. lazily evaluated),
in which case `initiation` and `args` must be decay-copied and moved
as required.
A helper function template `async_initiate` has also been added as a
wrapper for the invocation of `async_result<>::initiate`. For backward
compatibility, this function supports both the old and new async_result
forms.
Four new protocol classes have been added:
- asio::generic::datagram_protocol
- asio::generic::raw_protocol
- asio::generic::seq_packet_protocol
- asio::generic::stream_protocol
These classes implement the Protocol type requirements, but allow the
user to specify the address family (e.g. AF_INET) and protocol type
(e.g. IPPROTO_TCP) at runtime.
A new endpoint class template, asio::generic::basic_endpoint, has been
added to support these new protocol classes. This endpoint can hold any
other endpoint type, provided its native representation fits into a
sockaddr_storage object.
When using C++11, it is now possible to perform move construction from a
socket (or acceptor) object to convert to the more generic protocol's
socket (or acceptor) type. If the protocol conversion is valid:
Protocol1 p1 = ...;
Protocol2 p2(p1);
then the corresponding socket conversion is allowed:
Protocol1::socket socket1(io_service);
...
Protocol2::socket socket2(std::move(socket1));
For example, one possible conversion is from a TCP socket to a generic
stream-oriented socket:
asio::ip::tcp::socket socket1(io_service);
...
asio::generic::stream_protocol::socket socket2(std::move(socket1));
The conversion is also available for move-assignment. Note that these
conversions are not limited to the newly added generic protocol classes.
User-defined protocols may take advantage of this feature by similarly
ensuring the conversion from Protocol1 to Protocol2 is valid, as above.
As a convenience, the socket acceptor's accept() and async_accept()
functions have been changed so that they can directly accept into a
different protocol's socket type, provided the protocol conversion is
valid. For example, the following is now possible:
asio::ip::tcp::acceptor acceptor(io_service);
...
asio::generic::stream_protocol::socket socket1(io_service);
acceptor.accept(socket1);
[SVN r84363]
Add new overloads of the SSL stream's handshake() and async_handshake()
functions, that accepts a ConstBufferSequence to be used as initial
input to the ssl engine for the handshake procedure.
Thanks go to Nick Jones <nick dot fa dot jones at gmail dot com>, on
whose work this commit is partially based.
[SVN r84319]
