| 45 | template <typename T, |
| 46 | boost::asio::completion_token_for<void(boost::system::error_code)> CompletionToken> |
| 47 | auto async_write_messages(tcp::socket& socket, |
| 48 | const T& message, std::size_t repeat_count, |
| 49 | CompletionToken&& token) |
| 50 | // The return type of the initiating function is deduced from the combination |
| 51 | // of: |
| 52 | // |
| 53 | // - the CompletionToken type, |
| 54 | // - the completion handler signature, and |
| 55 | // - the asynchronous operation's initiation function object. |
| 56 | // |
| 57 | // When the completion token is a simple callback, the return type is always |
| 58 | // void. In this example, when the completion token is boost::asio::yield_context |
| 59 | // (used for stackful coroutines) the return type would also be void, as |
| 60 | // there is no non-error argument to the completion handler. When the |
| 61 | // completion token is boost::asio::use_future it would be std::future<void>. When |
| 62 | // the completion token is boost::asio::deferred, the return type differs for each |
| 63 | // asynchronous operation. |
| 64 | // |
| 65 | // In C++20 we can omit the return type as it is automatically deduced from |
| 66 | // the return type of boost::asio::async_compose. |
| 67 | { |
| 68 | // Encode the message and copy it into an allocated buffer. The buffer will |
| 69 | // be maintained for the lifetime of the composed asynchronous operation. |
| 70 | std::ostringstream os; |
| 71 | os << message; |
| 72 | std::unique_ptr<std::string> encoded_message(new std::string(os.str())); |
| 73 | |
| 74 | // Create a steady_timer to be used for the delay between messages. |
| 75 | std::unique_ptr<boost::asio::steady_timer> delay_timer( |
| 76 | new boost::asio::steady_timer(socket.get_executor())); |
| 77 | |
| 78 | // The boost::asio::async_compose function takes: |
| 79 | // |
| 80 | // - our asynchronous operation implementation, |
| 81 | // - the completion token, |
| 82 | // - the completion handler signature, and |
| 83 | // - any I/O objects (or executors) used by the operation |
| 84 | // |
| 85 | // It then wraps our implementation, which is implemented here as a stackless |
| 86 | // coroutine in a lambda, in an intermediate completion handler that meets the |
| 87 | // requirements of a conforming asynchronous operation. This includes |
| 88 | // tracking outstanding work against the I/O executors associated with the |
| 89 | // operation (in this example, this is the socket's executor). |
| 90 | // |
| 91 | // The first argument to our lambda is a reference to the enclosing |
| 92 | // intermediate completion handler. This intermediate completion handler is |
| 93 | // provided for us by the boost::asio::async_compose function, and takes care |
| 94 | // of all the details required to implement a conforming asynchronous |
| 95 | // operation. When calling an underlying asynchronous operation, we pass it |
| 96 | // this enclosing intermediate completion handler as the completion token. |
| 97 | // |
| 98 | // All arguments to our lambda after the first must be defaulted to allow the |
| 99 | // state machine to be started, as well as to allow the completion handler to |
| 100 | // match the completion signature of both the async_write and |
| 101 | // steady_timer::async_wait operations. |
| 102 | return boost::asio::async_compose< |
| 103 | CompletionToken, void(boost::system::error_code)>( |
| 104 | [ |