couchbase 3.0.0.alpha.3 → 3.0.1

data/ext/third_party/asio/asio/src/doc/overview/buffers.qbk

@@ -1,163 +0,0 @@
-[/
- / Copyright (c) 2003-2020 Christopher M. Kohlhoff (chris at kohlhoff dot com)
- /
- / Distributed under the Boost Software License, Version 1.0. (See accompanying
- / file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
- /]
-
-[section:buffers Buffers]
-
-Fundamentally, I/O involves the transfer of data to and from contiguous regions
-of memory, called buffers. These buffers can be simply expressed as a tuple
-consisting of a pointer and a size in bytes. However, to allow the development
-of efficient network applications, Asio includes support for scatter-gather
-operations. These operations involve one or more buffers:
-
-* A scatter-read receives data into multiple buffers.
-* A gather-write transmits multiple buffers.
-
-Therefore we require an abstraction to represent a collection of buffers. The
-approach used in Asio is to define a type (actually two types) to
-represent a single buffer. These can be stored in a container, which may be
-passed to the scatter-gather operations.
-
-In addition to specifying buffers as a pointer and size in bytes, Asio makes a
-distinction between modifiable memory (called mutable) and non-modifiable
-memory (where the latter is created from the storage for a const-qualified
-variable). These two types could therefore be defined as follows:
-
-  typedef std::pair<void*, std::size_t> mutable_buffer;
-  typedef std::pair<const void*, std::size_t> const_buffer;
-
-Here, a mutable_buffer would be convertible to a const_buffer, but conversion
-in the opposite direction is not valid.
-
-However, Asio does not use the above definitions as-is, but instead defines two
-classes: `mutable_buffer` and `const_buffer`. The goal of these is to provide
-an opaque representation of contiguous memory, where:
-
-* Types behave as std::pair would in conversions. That is, a `mutable_buffer` is
-  convertible to a `const_buffer`, but the opposite conversion is disallowed.
-
-* There is protection against buffer overruns. Given a buffer instance, a user
-  can only create another buffer representing the same range of memory or a
-  sub-range of it. To provide further safety, the library also includes
-  mechanisms for automatically determining the size of a buffer from an array,
-  `boost::array` or `std::vector` of POD elements, or from a `std::string`.
-
-* The underlying memory is explicitly accessed using the `data()` member
-  function. In general an application should never need to do this, but it is
-  required by the library implementation to pass the raw memory to the
-  underlying operating system functions.
-
-Finally, multiple buffers can be passed to scatter-gather operations (such as
-[link asio.reference.read read()] or [link asio.reference.write write()]) by
-putting the buffer objects into a container. The `MutableBufferSequence` and
-`ConstBufferSequence` concepts have been defined so that containers such as
-`std::vector`, `std::list`, `std::array` or `boost::array` can be used.
-
-[heading Streambuf for Integration with Iostreams]
-
-The class `asio::basic_streambuf` is derived from `std::basic_streambuf` to
-associate the input sequence and output sequence with one or more objects of
-some character array type, whose elements store arbitrary values. These
-character array objects are internal to the streambuf object, but direct access
-to the array elements is provided to permit them to be used with I/O
-operations, such as the send or receive operations of a socket:
-
-* The input sequence of the streambuf is accessible via the [link
-  asio.reference.basic_streambuf.data data()] member function. The return type
-  of this function meets the `ConstBufferSequence` requirements.
-
-* The output sequence of the streambuf is accessible via the [link
-  asio.reference.basic_streambuf.prepare prepare()] member function. The return
-  type of this function meets the `MutableBufferSequence` requirements.
-
-* Data is transferred from the front of the output sequence to the back of the
-  input sequence by calling the [link asio.reference.basic_streambuf.commit
-  commit()] member function.
-
-* Data is removed from the front of the input sequence by calling the [link
-  asio.reference.basic_streambuf.consume consume()] member function.
-
-The streambuf constructor accepts a `size_t` argument specifying the maximum of
-the sum of the sizes of the input sequence and output sequence. Any operation
-that would, if successful, grow the internal data beyond this limit will throw
-a `std::length_error` exception.
-
-[heading Bytewise Traversal of Buffer Sequences]
-
-The `buffers_iterator<>` class template allows buffer sequences (i.e. types
-meeting `MutableBufferSequence` or `ConstBufferSequence` requirements) to be
-traversed as though they were a contiguous sequence of bytes. Helper functions
-called buffers_begin() and buffers_end() are also provided, where the
-buffers_iterator<> template parameter is automatically deduced.
-
-As an example, to read a single line from a socket and into a `std::string`,
-you may write:
-
-  asio::streambuf sb;
-  ...
-  std::size_t n = asio::read_until(sock, sb, '\n');
-  asio::streambuf::const_buffers_type bufs = sb.data();
-  std::string line(
-      asio::buffers_begin(bufs),
-      asio::buffers_begin(bufs) + n);
-
-[heading Buffer Debugging]
-
-Some standard library implementations, such as the one that ships with
-Microsoft Visual C++ 8.0 and later, provide a feature called iterator
-debugging. What this means is that the validity of iterators is checked at
-runtime. If a program tries to use an iterator that has been invalidated, an
-assertion will be triggered. For example:
-
-  std::vector<int> v(1)
-  std::vector<int>::iterator i = v.begin();
-  v.clear(); // invalidates iterators
-  *i = 0; // assertion!
-
-Asio takes advantage of this feature to add buffer debugging. Consider the
-following code:
-
-  void dont_do_this()
-  {
-   std::string msg = "Hello, world!";
-   asio::async_write(sock, asio::buffer(msg), my_handler);
-  }
-
-When you call an asynchronous read or write you need to ensure that the buffers
-for the operation are valid until the completion handler is called. In the
-above example, the buffer is the `std::string` variable `msg`. This variable is
-on the stack, and so it goes out of scope before the asynchronous operation
-completes. If you're lucky then the application will crash, but random failures
-are more likely.
-
-When buffer debugging is enabled, Asio stores an iterator into the string until
-the asynchronous operation completes, and then dereferences it to check its
-validity. In the above example you would observe an assertion failure just
-before Asio tries to call the completion handler.
-
-This feature is automatically made available for Microsoft Visual Studio 8.0 or
-later and for GCC when `_GLIBCXX_DEBUG` is defined. There is a performance cost
-to this checking, so buffer debugging is only enabled in debug builds. For
-other compilers it may be enabled by defining `ASIO_ENABLE_BUFFER_DEBUGGING`.
-It can also be explicitly disabled by defining `ASIO_DISABLE_BUFFER_DEBUGGING`.
-
-[heading See Also]
-
-[link asio.reference.buffer buffer],
-[link asio.reference.buffers_begin buffers_begin],
-[link asio.reference.buffers_end buffers_end],
-[link asio.reference.buffers_iterator buffers_iterator],
-[link asio.reference.const_buffer const_buffer],
-[link asio.reference.const_buffers_1 const_buffers_1],
-[link asio.reference.mutable_buffer mutable_buffer],
-[link asio.reference.mutable_buffers_1 mutable_buffers_1],
-[link asio.reference.streambuf streambuf],
-[link asio.reference.ConstBufferSequence ConstBufferSequence],
-[link asio.reference.MutableBufferSequence MutableBufferSequence],
-[link asio.examples.cpp03_examples.buffers buffers example (C++03)],
-[link asio.examples.cpp11_examples.buffers buffers example (c++11)].
-
-[endsect]

data/ext/third_party/asio/asio/src/doc/overview/concurrency_hint.qbk

@@ -1,88 +0,0 @@
-[/
- / Copyright (c) 2003-2020 Christopher M. Kohlhoff (chris at kohlhoff dot com)
- /
- / Distributed under the Boost Software License, Version 1.0. (See accompanying
- / file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
- /]
-
-[section:concurrency_hint Concurrency Hints]
-
-The [link asio.reference.io_context.io_context `io_context` constructor]
-allows programs to specify a concurrency hint. This is a suggestion to the
-`io_context` implementation as to the number of active threads that should be
-used for running completion handlers.
-
-When the Windows I/O completion port backend is in use, this value is passed
-to [^CreateIoCompletionPort].
-
-When a reactor-based backend is used, the implementation recognises the
-following special concurrency hint values:
-
-[table
-  [[Value][Description]]
-  [
-    [`1`]
-    [
-      The implementation assumes that the `io_context` will be run from a
-      single thread, and applies several optimisations based on this
-      assumption.
-    
-      For example, when a handler is posted from within another handler, the
-      new handler is added to a fast thread-local queue (with the consequence
-      that the new handler is held back until the currently executing handler
-      finishes).
-    ]
-  ]
-  [
-    [`ASIO_CONCURRENCY_HINT_UNSAFE`]
-    [
-      This special concurrency hint disables locking in both the scheduler and
-      reactor I/O. This hint has the following restrictions:
-
-      [mdash] Care must be taken to ensure that all operations on the
-      `io_context` and any of its associated I/O objects (such as sockets and
-      timers) occur in only one thread at a time.
-
-      [mdash] Asynchronous resolve operations fail with `operation_not_supported`.
-
-      [mdash] If a `signal_set` is used with the `io_context`, `signal_set`
-      objects cannot be used with any other io_context in the program.
-    ]
-  ]
-  [
-    [`ASIO_CONCURRENCY_HINT_UNSAFE_IO`]
-    [
-      This special concurrency hint disables locking in the reactor I/O. This
-      hint has the following restrictions:
-
-      [mdash] Care must be taken to ensure that run functions on the
-      `io_context`, and all operations on the context's associated I/O objects
-      (such as sockets and timers), occur in only one thread at a time.
-    ]
-  ]
-  [
-    [`ASIO_CONCURRENCY_HINT_SAFE`]
-    [
-      The default. The `io_context` provides full thread safety, and distinct
-      I/O objects may be used from any thread.
-    ]
-  ]
-]
-
-[teletype]
-The concurrency hint used by default-constructed `io_context` objects can be
-overridden at compile time by defining the `ASIO_CONCURRENCY_HINT_DEFAULT`
-macro. For example, specifying
-
-  -DASIO_CONCURRENCY_HINT_DEFAULT=1
-
-on the compiler command line means that a concurrency hint of `1` is used for
-all default-constructed `io_context` objects in the program. Similarly, the
-concurrency hint used by `io_context` objects constructed with `1` can be
-overridden by defining `ASIO_CONCURRENCY_HINT_1`. For example, passing
-
-  -DASIO_CONCURRENCY_HINT_1=ASIO_CONCURRENCY_HINT_UNSAFE
-  
-to the compiler will disable thread safety for all of these objects.
-
-[endsect]

data/ext/third_party/asio/asio/src/doc/overview/coroutine.qbk

@@ -1,51 +0,0 @@
-[/
- / Copyright (c) 2003-2020 Christopher M. Kohlhoff (chris at kohlhoff dot com)
- /
- / Distributed under the Boost Software License, Version 1.0. (See accompanying
- / file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
- /]
-
-[section:coroutine Stackless Coroutines]
-
-The [link asio.reference.coroutine `coroutine`] class provides support for
-stackless coroutines. Stackless coroutines enable programs to implement
-asynchronous logic in a synchronous manner, with minimal overhead, as shown in
-the following example:
-
-  struct session : asio::coroutine
-  {
-    boost::shared_ptr<tcp::socket> socket_;
-    boost::shared_ptr<std::vector<char> > buffer_;
-
-    session(boost::shared_ptr<tcp::socket> socket)
-      : socket_(socket),
-        buffer_(new std::vector<char>(1024))
-    {
-    }
-
-    void operator()(asio::error_code ec = asio::error_code(), std::size_t n = 0)
-    {
-      if (!ec) reenter (this)
-      {
-        for (;;)
-        {
-          yield socket_->async_read_some(asio::buffer(*buffer_), *this);
-          yield asio::async_write(*socket_, asio::buffer(*buffer_, n), *this);
-        }
-      }
-    }
-  };
-
-The `coroutine` class is used in conjunction with the pseudo-keywords
-`reenter`, `yield` and `fork`. These are preprocessor macros, and are
-implemented in terms of a `switch` statement using a technique similar to
-Duff's Device. The [link asio.reference.coroutine `coroutine`] class's
-documentation provides a complete description of these pseudo-keywords.
-
-[heading See Also]
-
-[link asio.reference.coroutine coroutine],
-[link asio.examples.cpp03_examples.http_server_4 HTTP Server 4 example],
-[link asio.overview.core.spawn Stackful Coroutines].
-
-[endsect]

data/ext/third_party/asio/asio/src/doc/overview/coroutines_ts.qbk

@@ -1,97 +0,0 @@
-[/
- / Copyright (c) 2003-2020 Christopher M. Kohlhoff (chris at kohlhoff dot com)
- /
- / Distributed under the Boost Software License, Version 1.0. (See accompanying
- / file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
- /]
-
-[section:coroutines_ts Coroutines TS Support]
-
-Support for the Coroutines TS is provided via the [link
-asio.reference.awaitable `awaitable`] class template, the [link
-asio.reference.use_awaitable_t `use_awaitable`] completion token, and the [link
-asio.reference.co_spawn `co_spawn()`] function. These facilities allow programs
-to implement asynchronous logic in a synchronous manner, in conjunction with
-the `co_await` keyword, as shown in the following example:
-
-  asio::co_spawn(executor,
-      [socket = std::move(socket)]() mutable
-      {
-        return echo(std::move(socket));
-      },
-      asio::detached);
-
-  // ...
-
-  asio::awaitable<void> echo(tcp::socket socket)
-  {
-    try
-    {
-      char data[1024];
-      for (;;)
-      {
-        std::size_t n = co_await socket.async_read_some(asio::buffer(data), asio::use_awaitable);
-        co_await async_write(socket, asio::buffer(data, n), asio::use_awaitable);
-      }
-    }
-    catch (std::exception& e)
-    {
-      std::printf("echo Exception: %s\n", e.what());
-    }
-  }
-
-The first argument to `co_spawn()` is an [link asio.reference.Executor1
-executor] that determines the context in which the coroutine is permitted to
-execute. For example, a server's per-client object may consist of multiple
-coroutines; they should all run on the same `strand` so that no explicit
-synchronisation is required.
-
-The second argument is a nullary function object that returns a [link
-asio.reference.awaitable `asio::awaitable<R>`],
-where `R` is the type of return value produced by the coroutine. In the above
-example, the coroutine returns `void`.
-
-The third argument is a completion token, and this is used by `co_spawn()` to
-produce a completion handler with signature `void(std::exception_ptr, R)`. This
-completion handler is invoked with the result of the coroutine once it has
-finished. In the above example we pass a completion token type, [link
-asio.reference.detached `asio::detached`], which is used to explicitly ignore
-the result of an asynchronous operation.
-
-In this example the body of the coroutine is implemented in the `echo`
-function. When the `use_awaitable` completion token is passed to an
-asynchronous operation, the operation's initiating function returns an
-`awaitable` that may be used with the `co_await` keyword:
-
-  std::size_t n = co_await socket.async_read_some(asio::buffer(data), asio::use_awaitable);
-
-Where an asynchronous operation's handler signature has the form:
-
-  void handler(asio::error_code ec, result_type result);
-
-the resulting type of the `co_await` expression is `result_type`. In the
-`async_read_some` example above, this is `size_t`. If the asynchronous
-operation fails, the `error_code` is converted into a `system_error` exception
-and thrown.
-
-Where a handler signature has the form:
-
-  void handler(asio::error_code ec);
-
-the `co_await` expression produces a `void` result. As above, an error is
-passed back to the coroutine as a `system_error` exception.
-
-[heading See Also]
-
-[link asio.reference.co_spawn co_spawn],
-[link asio.reference.detached detached],
-[link asio.reference.redirect_error redirect_error],
-[link asio.reference.awaitable awaitable],
-[link asio.reference.use_awaitable_t use_awaitable_t],
-[link asio.reference.use_awaitable use_awaitable],
-[link asio.reference.this_coro__executor this_coro::executor],
-[link asio.examples.cpp17_examples.coroutines_ts_support Coroutines TS examples],
-[link asio.overview.core.spawn Stackful Coroutines],
-[link asio.overview.core.coroutine Stackless Coroutines].
-
-[endsect]

data/ext/third_party/asio/asio/src/doc/overview/cpp2011.qbk

@@ -1,271 +0,0 @@
-[/
- / Copyright (c) 2003-2020 Christopher M. Kohlhoff (chris at kohlhoff dot com)
- /
- / Distributed under the Boost Software License, Version 1.0. (See accompanying
- / file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
- /]
-
-[section:cpp2011 C++ 2011 Support]
-
-[/boostify: non-boost docs start here]
-
-[link asio.overview.cpp2011.system_error System Errors and Error Codes]
-
-[/boostify: non-boost docs end here]
-
-[link asio.overview.cpp2011.move_objects Movable I/O Objects]
-
-[link asio.overview.cpp2011.move_handlers Movable Handlers]
-
-[link asio.overview.cpp2011.variadic Variadic Templates]
-
-[link asio.overview.cpp2011.array Array Container]
-
-[link asio.overview.cpp2011.atomic Atomics]
-
-[link asio.overview.cpp2011.shared_ptr Shared Pointers]
-
-[link asio.overview.cpp2011.chrono Chrono]
-
-[link asio.overview.cpp2011.futures Futures]
-
-[/boostify: non-boost docs start here]
-
-[section:system_error System Errors and Error Codes]
-
-When available, Asio can use the `std::error_code` and `std::system_error`
-classes for reporting errors. In this case, the names `asio::error_code` and
-`asio::system_error` will be typedefs for these standard classes.
-
-System error support is automatically enabled for [^g++] 4.6 and later, when
-the [^-std=c++0x] or [^-std=gnu++0x] compiler options are used. It may be
-disabled by defining `ASIO_DISABLE_STD_SYSTEM_ERROR`, or explicitly enabled for
-other compilers by defining `ASIO_HAS_STD_SYSTEM_ERROR`.
-
-[endsect]
-
-[/boostify: non-boost docs end here]
-
-[section:move_objects Movable I/O Objects]
-
-When move support is available (via rvalue references), Asio allows move
-construction and assignment of sockets, serial ports, POSIX descriptors and
-Windows handles.
-
-Move support allows you to write code like:
-
-  tcp::socket make_socket(io_context& i)
-  {
-    tcp::socket s(i);
-    ...
-    std::move(s);
-  }
-
-or:
-
-  class connection : public enable_shared_from_this<connection>
-  {
-  private:
-    tcp::socket socket_;
-    ...
-  public:
-    connection(tcp::socket&& s) : socket_(std::move(s)) {}
-    ...
-  };
-
-  ...
-
-  class server
-  {
-  private:
-    tcp::acceptor acceptor_;
-    ...
-    void handle_accept(error_code ec, tcp::socket socket)
-    {
-      if (!ec)
-        std::make_shared<connection>(std::move(socket))->go();
-      acceptor_.async_accept(...);
-    }
-    ...
-  };
-
-as well as:
-
-  std::vector<tcp::socket> sockets;
-  sockets.push_back(tcp::socket(...));
-
-A word of warning: There is nothing stopping you from moving these objects
-while there are pending asynchronous operations, but it is unlikely to be a
-good idea to do so. In particular, composed operations like [link
-asio.reference.async_read async_read()] store a reference to the stream object.
-Moving during the composed operation means that the composed operation may
-attempt to access a moved-from object.
-
-Move support is automatically enabled for [^g++] 4.5 and later, when the
-[^-std=c++0x] or [^-std=gnu++0x] compiler options are used. It may be disabled
-by defining `ASIO_DISABLE_MOVE`, or explicitly enabled for other compilers by
-defining `ASIO_HAS_MOVE`. Note that these macros also affect the availability
-of [link asio.overview.cpp2011.move_handlers movable handlers].
-
-[endsect]
-
-[section:move_handlers Movable Handlers]
-
-With C++11 and later, user-defined completion handlers are only required to be
-move constructible, and are not required to be copy constructible.
-
-When move support is enabled, asynchronous that are documented as follows:
-
-  template <typename Handler>
-  void async_XYZ(..., Handler handler);
-
-are actually declared as:
-
-  template <typename Handler>
-  void async_XYZ(..., Handler&& handler);
-
-The handler argument is perfectly forwarded and the move construction occurs
-within the body of `async_XYZ()`. This ensures that all other function
-arguments are evaluated prior to the move. This is critical when the other
-arguments to `async_XYZ()` are members of the handler. For example:
-
-  struct my_operation
-  {
-    unique_ptr<tcp::socket> socket;
-    unique_ptr<vector<char>> buffer;
-    ...
-    void operator(error_code ec, size_t length)
-    {
-      ...
-      socket->async_read_some(asio::buffer(*buffer), std::move(*this));
-      ...
-    }
-  };
-
-Move support is automatically enabled for [^g++] 4.5 and later, when the
-[^-std=c++0x] or [^-std=gnu++0x] compiler options are used. It may be disabled
-by defining `ASIO_DISABLE_MOVE`, or explicitly enabled for other compilers by
-defining `ASIO_HAS_MOVE`. Note that these macros also affect the availability
-of [link asio.overview.cpp2011.move_objects movable I/O objects].
-
-[endsect]
-
-[section:variadic Variadic Templates]
-
-When supported by a compiler, Asio can use variadic templates to implement the
-[link asio.reference.basic_socket_streambuf.connect
-basic_socket_streambuf::connect()] and [link
-asio.reference.basic_socket_iostream.connect basic_socket_iostream::connect()]
-functions.
-
-Support for variadic templates is automatically enabled for [^g++] 4.3 and
-later, when the [^-std=c++0x] or [^-std=gnu++0x] compiler options are used. It
-may be disabled by defining `ASIO_DISABLE_VARIADIC_TEMPLATES`, or explicitly
-enabled for other compilers by defining `ASIO_HAS_VARIADIC_TEMPLATES`.
-
-[endsect]
-
-[section:array Array Container]
-
-Where the standard library provides `std::array<>`, Asio:
-
-* Provides overloads for the [link asio.reference.buffer buffer()] function.
-
-* Uses it in preference to `boost::array<>` for the
-  [link asio.reference.ip__address_v4.bytes_type ip::address_v4::bytes_type] and
-  [link asio.reference.ip__address_v6.bytes_type ip::address_v6::bytes_type]
-  types.
-
-* Uses it in preference to `boost::array<>` where a fixed size array type is
-  needed in the implementation.
-
-Support for `std::array<>` is automatically enabled for [^g++] 4.3 and later,
-when the [^-std=c++0x] or [^-std=gnu++0x] compiler options are used, as well as
-for Microsoft Visual C++ 10. It may be disabled by defining
-`ASIO_DISABLE_STD_ARRAY`, or explicitly enabled for other compilers by
-defining `ASIO_HAS_STD_ARRAY`.
-
-[endsect]
-
-[section:atomic Atomics]
-
-Asio's implementation can use `std::atomic<>` in preference to
-`boost::detail::atomic_count`.
-
-Support for the standard atomic integer template is automatically enabled for
-[^g++] 4.5 and later, when the [^-std=c++0x] or [^-std=gnu++0x] compiler
-options are used. It may be disabled by defining `ASIO_DISABLE_STD_ATOMIC`, or
-explicitly enabled for other compilers by defining `ASIO_HAS_STD_ATOMIC`.
-
-[endsect]
-
-[section:shared_ptr Shared Pointers]
-
-Asio's implementation can use `std::shared_ptr<>` and `std::weak_ptr<>` in
-preference to the Boost equivalents.
-
-Support for the standard smart pointers is automatically enabled for [^g++] 4.3
-and later, when the [^-std=c++0x] or [^-std=gnu++0x] compiler options are used,
-as well as for Microsoft Visual C++ 10. It may be disabled by defining
-`ASIO_DISABLE_STD_SHARED_PTR`, or explicitly enabled for other compilers by
-defining `ASIO_HAS_STD_SHARED_PTR`.
-
-[endsect]
-
-[section:chrono Chrono]
-
-Asio provides timers based on the `std::chrono` facilities via the [link
-asio.reference.basic_waitable_timer basic_waitable_timer] class template.
-The typedefs [link asio.reference.system_timer system_timer], [link
-asio.reference.steady_timer steady_timer] and [link
-asio.reference.high_resolution_timer high_resolution_timer] utilise the
-standard clocks `system_clock`, `steady_clock` and `high_resolution_clock`
-respectively.
-
-Support for the `std::chrono` facilities is automatically enabled for [^g++]
-4.6 and later, when the [^-std=c++0x] or [^-std=gnu++0x] compiler options are
-used. (Note that, for [^g++], the draft-standard `monotonic_clock` is used in
-place of `steady_clock`.) Support may be disabled by defining
-`ASIO_DISABLE_STD_CHRONO`, or explicitly enabled for other compilers by
-defining `ASIO_HAS_STD_CHRONO`.
-
-When standard `chrono` is unavailable, Asio will otherwise use the Boost.Chrono
-library. The [link asio.reference.basic_waitable_timer basic_waitable_timer]
-class template may be used with either.
-
-[endsect]
-
-[section:futures Futures]
-
-The `asio::use_future` special value provides first-class support for returning a
-C++11 `std::future` from an asynchronous operation's initiating function.
-
-To use `asio::use_future`, pass it to an asynchronous operation instead of
-a normal completion handler. For example:
-
-  std::future<std::size_t> length =
-    my_socket.async_read_some(my_buffer, asio::use_future);
-
-Where a handler signature has the form:
-
-  void handler(asio::error_code ec, result_type result);
-
-the initiating function returns a `std::future` templated on `result_type`.
-In the above example, this is `std::size_t`. If the asynchronous operation
-fails, the `error_code` is converted into a `system_error` exception and
-passed back to the caller through the future.
-
-Where a handler signature has the form:
-
-  void handler(asio::error_code ec);
-
-the initiating function returns `std::future<void>`. As above, an error
-is passed back in the future as a `system_error` exception.
-
-[link asio.reference.use_future use_future],
-[link asio.reference.use_future_t use_future_t],
-[link asio.examples.cpp11_examples.futures Futures example (C++11)].
-
-[endsect]
-
-[endsect]