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');
The awaitable<>, co_spawn(), this_coro, detached, and redirect_error
facilities have been moved from the asio::experimental namespace to
namespace asio. As part of this change, the this_coro::token() awaitable
has been superseded by the asio::use_awaitable completion token.
Please note that the use_awaitable and redirect_error completion tokens
work only with asynchronous operations that use the new form of
async_result with member function initiate(). Furthermore, when using
use_awaitable, please be aware that the asynchronous operation is not
initiated until co_await is applied to the awaitable<>.
All I/O objects now have an additional Executor template parameter. This
template parameter defaults to the asio::executor type (the polymorphic
executor wrapper) but can be used to specify a user-defined executor
type.
I/O objects' constructors and functions that previously took an
asio::io_context& now accept either an Executor or a reference to a
concrete ExecutionContext (such as asio::io_context or
asio::thread_pool).
One potential point of breakage in existing user code is when reusing an
I/O object's io_context for constructing another I/O object, as in:
asio::steady_timer my_timer(my_socket.get_executor().context());
To fix this, either construct the second I/O object using the first I/O
object's executor:
asio::steady_timer my_timer(my_socket.get_executor());
or otherwise explicitly pass the io_context:
asio::steady_timer my_timer(my_io_context);
Define the preprocessor macro BOOST_ASIO_DISABLE_STD_STRING_VIEW to
force the use of std::experimental::string_view (assuming it is
available) when compiling in C++17 mode.
