| Home | Libraries | People | FAQ | More

##### test::basic_stream::rebind_executor::other

The socket type when rebound to the specified executor.

###### Synopsis

    using other = basic_stream< Executor1 >;

###### Types

Name | Description
--- | ---
buffer_type |
executor_type | The type of the executor associated with the object.
rebind_executor [constructor] | Rebinds the socket type to another executor.

###### Member Functions

Name | Description
--- | ---
append | Appends a string to the pending input data.
async_read_some | Start an asynchronous read.
async_write_some | Start an asynchronous write.
basic_stream | Move Constructor. — Construct a stream.
buffer | Direct input buffer access.
clear | Clear the pending input area.
close | Close the stream.
close_remote | Close the other end of the stream.
connect | Establish a connection.
get_executor | Return the executor associated with the object.
nread | Return the number of reads.
nread_bytes | Return the number of bytes read.
nwrite | Return the number of writes.
nwrite_bytes | Return the number of bytes written.
operator= | Move Assignment.
operator== |
read_size | Set the maximum number of bytes returned by read_some.
read_some | Read some data from the stream.
str | Returns a string view representing the pending input data.
write_size | Set the maximum number of bytes returned by write_some.
write_some | Write some data to the stream.
~basic_stream [destructor] | Destructor.

An instance of this class simulates a traditional socket, while also providing features useful for unit testing. Each endpoint maintains an independent buffer called the input area. Writes from one endpoint append data to the peer's pending input area. When an endpoint performs a read and data is present in the input area, the data is delivered to the blocking or asynchronous operation. Otherwise the operation is blocked or deferred until data is made available, or until the endpoints become disconnected. These streams may be used anywhere an algorithm accepts a reference to a synchronous or asynchronous read or write stream. It is possible to use a test stream in a call to `net::read_until`, or in a call to `boost::beast::http::async_write` for example. As with Boost.Asio I/O objects, a `stream` constructs with a reference to the `net::io_context` to use for handling asynchronous I/O. For asynchronous operations, the stream follows the same rules as a traditional asio socket with respect to how completion handlers for asynchronous operations are performed. To facilitate testing, these streams support some additional features:

- The input area, represented by a `beast::basic_flat_buffer`, may be directly accessed by the caller to inspect the contents before or after the remote endpoint writes data. This allows a unit test to verify that the received data matches.
- Data may be manually appended to the input area. This data will delivered in the next call to `stream::read_some` or `stream::async_read_some`. This allows predefined test vectors to be set up for testing read algorithms.
- The stream may be constructed with a fail count. The stream will eventually fail with a predefined error after a certain number of operations, where the number of operations is controlled by the test. When a test loops over a range of operation counts, it is possible to exercise every possible point of failure in the algorithm being tested. When used correctly the technique allows the tests to reach a high percentage of code coverage.

###### Thread Safety

Distinct objects:Safe.

Shared objects:Unsafe. The application must also ensure that all asynchronous operations are performed within the same implicit or explicit strand.