summaryrefslogtreecommitdiffstatshomepage
path: root/3rdparty/asio/src/doc/overview
diff options
context:
space:
mode:
Diffstat (limited to '3rdparty/asio/src/doc/overview')
-rw-r--r--3rdparty/asio/src/doc/overview/allocation.qbk58
-rw-r--r--3rdparty/asio/src/doc/overview/async.qbk185
-rw-r--r--3rdparty/asio/src/doc/overview/async_op1.dot78
-rw-r--r--3rdparty/asio/src/doc/overview/async_op1.pngbin24260 -> 0 bytes
-rw-r--r--3rdparty/asio/src/doc/overview/async_op2.dot78
-rw-r--r--3rdparty/asio/src/doc/overview/async_op2.pngbin24542 -> 0 bytes
-rw-r--r--3rdparty/asio/src/doc/overview/basics.qbk106
-rw-r--r--3rdparty/asio/src/doc/overview/bsd_sockets.qbk270
-rw-r--r--3rdparty/asio/src/doc/overview/buffers.qbk163
-rw-r--r--3rdparty/asio/src/doc/overview/coroutine.qbk51
-rw-r--r--3rdparty/asio/src/doc/overview/cpp2011.qbk275
-rw-r--r--3rdparty/asio/src/doc/overview/handler_tracking.qbk102
-rw-r--r--3rdparty/asio/src/doc/overview/implementation.qbk305
-rw-r--r--3rdparty/asio/src/doc/overview/iostreams.qbk72
-rw-r--r--3rdparty/asio/src/doc/overview/line_based.qbk118
-rw-r--r--3rdparty/asio/src/doc/overview/other_protocols.qbk94
-rw-r--r--3rdparty/asio/src/doc/overview/posix.qbk152
-rw-r--r--3rdparty/asio/src/doc/overview/proactor.dot100
-rw-r--r--3rdparty/asio/src/doc/overview/proactor.pngbin30877 -> 0 bytes
-rw-r--r--3rdparty/asio/src/doc/overview/protocols.qbk149
-rw-r--r--3rdparty/asio/src/doc/overview/rationale.qbk54
-rw-r--r--3rdparty/asio/src/doc/overview/reactor.qbk44
-rw-r--r--3rdparty/asio/src/doc/overview/serial_ports.qbk45
-rw-r--r--3rdparty/asio/src/doc/overview/signals.qbk44
-rw-r--r--3rdparty/asio/src/doc/overview/spawn.qbk102
-rw-r--r--3rdparty/asio/src/doc/overview/ssl.qbk123
-rw-r--r--3rdparty/asio/src/doc/overview/strands.qbk85
-rw-r--r--3rdparty/asio/src/doc/overview/streams.qbk62
-rw-r--r--3rdparty/asio/src/doc/overview/sync_op.dot67
-rw-r--r--3rdparty/asio/src/doc/overview/sync_op.pngbin20243 -> 0 bytes
-rw-r--r--3rdparty/asio/src/doc/overview/threads.qbk66
-rw-r--r--3rdparty/asio/src/doc/overview/timers.qbk52
-rw-r--r--3rdparty/asio/src/doc/overview/windows.qbk126
33 files changed, 0 insertions, 3226 deletions
diff --git a/3rdparty/asio/src/doc/overview/allocation.qbk b/3rdparty/asio/src/doc/overview/allocation.qbk
deleted file mode 100644
index ecdc71a5011..00000000000
--- a/3rdparty/asio/src/doc/overview/allocation.qbk
+++ /dev/null
@@ -1,58 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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:allocation Custom Memory Allocation]
-
-Many asynchronous operations need to allocate an object to store state
-associated with the operation. For example, a Win32 implementation needs
-`OVERLAPPED`-derived objects to pass to Win32 API functions.
-
-Furthermore, programs typically contain easily identifiable chains of
-asynchronous operations. A half duplex protocol implementation (e.g. an HTTP
-server) would have a single chain of operations per client (receives followed
-by sends). A full duplex protocol implementation would have two chains
-executing in parallel. Programs should be able to leverage this knowledge to
-reuse memory for all asynchronous operations in a chain.
-
-Given a copy of a user-defined `Handler` object `h`, if the implementation
-needs to allocate memory associated with that handler it will execute the code:
-
- void* pointer = asio_handler_allocate(size, &h);
-
-Similarly, to deallocate the memory it will execute:
-
- asio_handler_deallocate(pointer, size, &h);
-
-These functions are located using argument-dependent lookup. The implementation
-provides default implementations of the above functions in the `asio` namespace:
-
- void* asio_handler_allocate(size_t, ...);
- void asio_handler_deallocate(void*, size_t, ...);
-
-which are implemented in terms of `::operator new()` and `::operator delete()`
-respectively.
-
-The implementation guarantees that the deallocation will occur before the
-associated handler is invoked, which means the memory is ready to be reused for
-any new asynchronous operations started by the handler.
-
-The custom memory allocation functions may be called from any user-created
-thread that is calling a library function. The implementation guarantees that,
-for the asynchronous operations included the library, the implementation will
-not make concurrent calls to the memory allocation functions for that handler.
-The implementation will insert appropriate memory barriers to ensure correct
-memory visibility should allocation functions need to be called from different
-threads.
-
-[heading See Also]
-
-[link asio.reference.asio_handler_allocate asio_handler_allocate],
-[link asio.reference.asio_handler_deallocate asio_handler_deallocate],
-[link asio.examples.cpp03_examples.allocation custom memory allocation example (C++03)],
-[link asio.examples.cpp11_examples.allocation custom memory allocation example (C++11)].
-
-[endsect]
diff --git a/3rdparty/asio/src/doc/overview/async.qbk b/3rdparty/asio/src/doc/overview/async.qbk
deleted file mode 100644
index ff627872416..00000000000
--- a/3rdparty/asio/src/doc/overview/async.qbk
+++ /dev/null
@@ -1,185 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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:async The Proactor Design Pattern: Concurrency Without Threads]
-
-The Asio library offers side-by-side support for synchronous and asynchronous
-operations. The asynchronous support is based on the Proactor design pattern
-[link asio.overview.core.async.references \[POSA2\]]. The advantages and
-disadvantages of this approach, when compared to a synchronous-only or Reactor
-approach, are outlined below.
-
-[heading Proactor and Asio]
-
-Let us examine how the Proactor design pattern is implemented in Asio,
-without reference to platform-specific details.
-
-[$proactor.png]
-
-[*Proactor design pattern (adapted from \[POSA2\])]
-
-[mdash] Asynchronous Operation
-
-[:Defines an operation that is executed asynchronously, such as an asynchronous
-read or write on a socket.]
-
-[mdash] Asynchronous Operation Processor
-
-[:Executes asynchronous operations and queues events on a completion event
-queue when operations complete. From a high-level point of view, internal
-services like `reactive_socket_service` are asynchronous operation processors.]
-
-[mdash] Completion Event Queue
-
-[:Buffers completion events until they are dequeued by an asynchronous event
-demultiplexer.]
-
-[mdash] Completion Handler
-
-[:Processes the result of an asynchronous operation. These are function
-objects, often created using `boost::bind`.]
-
-[mdash] Asynchronous Event Demultiplexer
-
-[:Blocks waiting for events to occur on the completion event queue, and returns
-a completed event to its caller.]
-
-[mdash] Proactor
-
-[:Calls the asynchronous event demultiplexer to dequeue events, and dispatches
-the completion handler (i.e. invokes the function object) associated with the
-event. This abstraction is represented by the `io_context` class.]
-
-[mdash] Initiator
-
-[:Application-specific code that starts asynchronous operations. The initiator
-interacts with an asynchronous operation processor via a high-level interface
-such as `basic_stream_socket`, which in turn delegates to a service like
-`reactive_socket_service`.]
-
-[heading Implementation Using Reactor]
-
-On many platforms, Asio implements the Proactor design pattern in terms
-of a Reactor, such as `select`, `epoll` or `kqueue`. This implementation
-approach corresponds to the Proactor design pattern as follows:
-
-[mdash] Asynchronous Operation Processor
-
-[:A reactor implemented using `select`, `epoll` or `kqueue`. When the reactor
-indicates that the resource is ready to perform the operation, the processor
-executes the asynchronous operation and enqueues the associated completion
-handler on the completion event queue.]
-
-[mdash] Completion Event Queue
-
-[:A linked list of completion handlers (i.e. function objects).]
-
-[mdash] Asynchronous Event Demultiplexer
-
-[:This is implemented by waiting on an event or condition variable until a
-completion handler is available in the completion event queue.]
-
-[heading Implementation Using Windows Overlapped I/O]
-
-On Windows NT, 2000 and XP, Asio takes advantage of overlapped I/O to
-provide an efficient implementation of the Proactor design pattern. This
-implementation approach corresponds to the Proactor design pattern as follows:
-
-[mdash] Asynchronous Operation Processor
-
-[:This is implemented by the operating system. Operations are initiated by
-calling an overlapped function such as `AcceptEx`.]
-
-[mdash] Completion Event Queue
-
-[:This is implemented by the operating system, and is associated with an I/O
-completion port. There is one I/O completion port for each `io_context`
-instance.]
-
-[mdash] Asynchronous Event Demultiplexer
-
-[:Called by Asio to dequeue events and their associated completion
-handlers.]
-
-[heading Advantages]
-
-[mdash] Portability.
-
-[:Many operating systems offer a native asynchronous I/O API (such as
-overlapped I/O on __Windows__) as the preferred option for developing high
-performance network applications. The library may be implemented in terms of
-native asynchronous I/O. However, if native support is not available, the
-library may also be implemented using synchronous event demultiplexors that
-typify the Reactor pattern, such as __POSIX__ `select()`.]
-
-[mdash] Decoupling threading from concurrency.
-
-[:Long-duration operations are performed asynchronously by the implementation
-on behalf of the application. Consequently applications do not need to spawn
-many threads in order to increase concurrency.]
-
-[mdash] Performance and scalability.
-
-[:Implementation strategies such as thread-per-connection (which a
-synchronous-only approach would require) can degrade system performance, due to
-increased context switching, synchronisation and data movement among CPUs. With
-asynchronous operations it is possible to avoid the cost of context switching
-by minimising the number of operating system threads [mdash] typically a
-limited resource [mdash] and only activating the logical threads of control
-that have events to process.]
-
-[mdash] Simplified application synchronisation.
-
-[:Asynchronous operation completion handlers can be written as though they
-exist in a single-threaded environment, and so application logic can be
-developed with little or no concern for synchronisation issues.]
-
-[mdash] Function composition.
-
-[:Function composition refers to the implementation of functions to provide a
-higher-level operation, such as sending a message in a particular format. Each
-function is implemented in terms of multiple calls to lower-level read or write
-operations.]
-
-[:For example, consider a protocol where each message consists of a
-fixed-length header followed by a variable length body, where the length of the
-body is specified in the header. A hypothetical read_message operation could be
-implemented using two lower-level reads, the first to receive the header and,
-once the length is known, the second to receive the body.]
-
-[:To compose functions in an asynchronous model, asynchronous operations can be
-chained together. That is, a completion handler for one operation can initiate
-the next. Starting the first call in the chain can be encapsulated so that the
-caller need not be aware that the higher-level operation is implemented as a
-chain of asynchronous operations.]
-
-[:The ability to compose new operations in this way simplifies the development
-of higher levels of abstraction above a networking library, such as functions
-to support a specific protocol.]
-
-[heading Disadvantages]
-
-[mdash] Program complexity.
-
-[:It is more difficult to develop applications using asynchronous mechanisms
-due to the separation in time and space between operation initiation and
-completion. Applications may also be harder to debug due to the inverted flow
-of control.]
-
-[mdash] Memory usage.
-
-[:Buffer space must be committed for the duration of a read or write operation,
-which may continue indefinitely, and a separate buffer is required for each
-concurrent operation. The Reactor pattern, on the other hand, does not require
-buffer space until a socket is ready for reading or writing.]
-
-[heading References]
-
-\[POSA2\] D. Schmidt et al, ['Pattern Oriented Software Architecture, Volume
-2]. Wiley, 2000.
-
-[endsect]
diff --git a/3rdparty/asio/src/doc/overview/async_op1.dot b/3rdparty/asio/src/doc/overview/async_op1.dot
deleted file mode 100644
index cbb95fb6949..00000000000
--- a/3rdparty/asio/src/doc/overview/async_op1.dot
+++ /dev/null
@@ -1,78 +0,0 @@
-digraph g
-{
- graph
- [
- nodesep="0.2"
- ];
-
- edge
- [
- fontname="Helvetica",
- fontsize=10,
- labelfontname="Helvetica",
- labelfontsize=10
- ];
-
- node
- [
- fontname="Helvetica",
- fontsize=10,
- shape=box
- ];
-
- edge
- [
- arrowhead="open"
- ]
-
- // Program elements.
- {
- operating_system [ label="Operating System", shape=ellipse ];
- io_context [ label="io_context" ];
- io_object [ label="I/O Object\ne.g. socket" ];
- your_program [ label="Your Program" ];
- your_completion_handler [ label="Your Completion Handler" ];
- }
-
- // Owning relationships.
- {
- edge [ arrowtail="diamond" ];
- your_program:e -> your_completion_handler:n;
- your_program:w -> io_object:nw;
- your_program:se -> io_context:ne;
- }
-
- // Non-owning relationships;
- {
- io_object:sw -> io_context:w;
- }
-
- // Visible actions.
- {
- edge [ style="dashed", color="#808080" ];
-
- // Forward actions.
- {
- your_program:sw -> io_object:n [ label="1" ];
- io_object:s -> io_context:nw [ label="2" ];
- io_context:s -> operating_system:n [ label="3" ];
- }
- }
-
- // Invisible actions.
- {
- edge [ style="invis" ];
-
- // Forward actions.
- {
- your_program:s -> io_context:n [ label="5" ];
- }
-
- // Reverse actions.
- {
- edge [ arrowhead="none", arrowtail="open" ];
- //io_context:s -> operating_system:n [ label="4" ];
- your_completion_handler:s -> io_context:e [ label="6" ];
- }
- }
-}
diff --git a/3rdparty/asio/src/doc/overview/async_op1.png b/3rdparty/asio/src/doc/overview/async_op1.png
deleted file mode 100644
index 464bc90e683..00000000000
--- a/3rdparty/asio/src/doc/overview/async_op1.png
+++ /dev/null
Binary files differ
diff --git a/3rdparty/asio/src/doc/overview/async_op2.dot b/3rdparty/asio/src/doc/overview/async_op2.dot
deleted file mode 100644
index 60a3275c391..00000000000
--- a/3rdparty/asio/src/doc/overview/async_op2.dot
+++ /dev/null
@@ -1,78 +0,0 @@
-digraph g
-{
- graph
- [
- nodesep="0.2"
- ];
-
- edge
- [
- fontname="Helvetica",
- fontsize=10,
- labelfontname="Helvetica",
- labelfontsize=10
- ];
-
- node
- [
- fontname="Helvetica",
- fontsize=10,
- shape=box
- ];
-
- edge
- [
- arrowhead="open"
- ]
-
- // Program elements.
- {
- operating_system [ label="Operating System", shape=ellipse ];
- io_context [ label="io_context" ];
- io_object [ label="I/O Object\ne.g. socket" ];
- your_program [ label="Your Program" ];
- your_completion_handler [ label="Your Completion Handler" ];
- }
-
- // Owning relationships.
- {
- edge [ arrowtail="diamond" ];
- your_program:e -> your_completion_handler:n;
- your_program:w -> io_object:nw;
- your_program:se -> io_context:ne;
- }
-
- // Non-owning relationships;
- {
- io_object:sw -> io_context:w;
- }
-
- // Visible actions.
- {
- edge [ style="dashed", color="#808080" ];
-
- // Forward actions.
- {
- your_program:s -> io_context:n [ label="5" ];
- }
-
- // Reverse actions.
- {
- edge [ arrowhead="none", arrowtail="open" ];
- io_context:s -> operating_system:n [ label="4" ];
- your_completion_handler:s -> io_context:e [ label="6" ];
- }
- }
-
- // Invisible actions.
- {
- edge [ style="invis" ];
-
- // Forward actions.
- {
- your_program:sw -> io_object:n [ label="1" ];
- io_object:s -> io_context:nw [ label="2" ];
- //io_context:s -> operating_system:n [ label="3" ];
- }
- }
-}
diff --git a/3rdparty/asio/src/doc/overview/async_op2.png b/3rdparty/asio/src/doc/overview/async_op2.png
deleted file mode 100644
index ba256ec8e7f..00000000000
--- a/3rdparty/asio/src/doc/overview/async_op2.png
+++ /dev/null
Binary files differ
diff --git a/3rdparty/asio/src/doc/overview/basics.qbk b/3rdparty/asio/src/doc/overview/basics.qbk
deleted file mode 100644
index c867563840a..00000000000
--- a/3rdparty/asio/src/doc/overview/basics.qbk
+++ /dev/null
@@ -1,106 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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:basics Basic Asio Anatomy]
-
-Asio may be used to perform both synchronous and asynchronous operations on I/O
-objects such as sockets. Before using Asio it may be useful to get a conceptual
-picture of the various parts of Asio, your program, and how they work together.
-
-As an introductory example, let's consider what happens when you perform a
-connect operation on a socket. We shall start by examining synchronous
-operations.
-
-[$sync_op.png]
-
-[*Your program] will have at least one [*io_context] object. The [*io_context]
-represents [*your program]'s link to the [*operating system]'s I/O services.
-
- asio::io_context io_context;
-
-To perform I/O operations [*your program] will need an [*I/O object] such as a
-TCP socket:
-
- asio::ip::tcp::socket socket(io_context);
-
-When a synchronous connect operation is performed, the following sequence of
-events occurs:
-
-1. [*Your program] initiates the connect operation by calling the [*I/O
-object]:
-
- socket.connect(server_endpoint);
-
-2. The [*I/O object] forwards the request to the [*io_context].
-
-3. The [*io_context] calls on the [*operating system] to perform the connect
-operation.
-
-4. The [*operating system] returns the result of the operation to the
-[*io_context].
-
-5. The [*io_context] translates any error resulting from the operation into an
-object of type `asio::error_code`. An `error_code` may be compared with
-specific values, or tested as a boolean (where a `false` result means that no
-error occurred). The result is then forwarded back up to the [*I/O object].
-
-6. The [*I/O object] throws an exception of type `asio::system_error` if the
-operation failed. If the code to initiate the operation had instead been
-written as:
-
- asio::error_code ec;
- socket.connect(server_endpoint, ec);
-
-then the `error_code` variable `ec` would be set to the result of the
-operation, and no exception would be thrown.
-
-When an asynchronous operation is used, a different sequence of events occurs.
-
-[$async_op1.png]
-
-1. [*Your program] initiates the connect operation by calling the [*I/O
-object]:
-
- socket.async_connect(server_endpoint, your_completion_handler);
-
-where `your_completion_handler` is a function or function object with the
-signature:
-
- void your_completion_handler(const asio::error_code& ec);
-
-The exact signature required depends on the asynchronous operation being
-performed. The reference documentation indicates the appropriate form for each
-operation.
-
-2. The [*I/O object] forwards the request to the [*io_context].
-
-3. The [*io_context] signals to the [*operating system] that it should start an
-asynchronous connect.
-
-Time passes. (In the synchronous case this wait would have been contained
-entirely within the duration of the connect operation.)
-
-[$async_op2.png]
-
-4. The [*operating system] indicates that the connect operation has completed
-by placing the result on a queue, ready to be picked up by the [*io_context].
-
-5. [*Your program] must make a call to `io_context::run()` (or to one of the
-similar [*io_context] member functions) in order for the result to be
-retrieved. A call to `io_context::run()` blocks while there are unfinished
-asynchronous operations, so you would typically call it as soon as you have
-started your first asynchronous operation.
-
-6. While inside the call to `io_context::run()`, the [*io_context] dequeues the
-result of the operation, translates it into an `error_code`, and then passes it
-to [*your completion handler].
-
-This is a simplified picture of how Asio operates. You will want to delve
-further into the documentation if your needs are more advanced, such as
-extending Asio to perform other types of asynchronous operations.
-
-[endsect]
diff --git a/3rdparty/asio/src/doc/overview/bsd_sockets.qbk b/3rdparty/asio/src/doc/overview/bsd_sockets.qbk
deleted file mode 100644
index acc67da29d4..00000000000
--- a/3rdparty/asio/src/doc/overview/bsd_sockets.qbk
+++ /dev/null
@@ -1,270 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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:bsd_sockets The BSD Socket API and Asio]
-
-The Asio library includes a low-level socket interface based on the BSD socket
-API, which is widely implemented and supported by extensive literature. It is
-also used as the basis for networking APIs in other languages, like Java. This
-low-level interface is designed to support the development of efficient and
-scalable applications. For example, it permits programmers to exert finer
-control over the number of system calls, avoid redundant data copying, minimise
-the use of resources like threads, and so on.
-
-Unsafe and error prone aspects of the BSD socket API not included. For example,
-the use of `int` to represent all sockets lacks type safety. The socket
-representation in Asio uses a distinct type for each protocol, e.g. for TCP one
-would use `ip::tcp::socket`, and for UDP one uses `ip::udp::socket`.
-
-The following table shows the mapping between the BSD socket API and Asio:
-
-[table
- [
- [BSD Socket API Elements]
- [Equivalents in Asio]
- ]
- [
- [socket descriptor - `int` (POSIX) or `SOCKET` (Windows)]
- [ For TCP: [link asio.reference.ip__tcp.socket ip::tcp::socket],
- [link asio.reference.ip__tcp.acceptor ip::tcp::acceptor]
-
- For UDP: [link asio.reference.ip__udp.socket ip::udp::socket]
-
- [link asio.reference.basic_socket basic_socket],
- [link asio.reference.basic_stream_socket basic_stream_socket],
- [link asio.reference.basic_datagram_socket basic_datagram_socket],
- [link asio.reference.basic_raw_socket basic_raw_socket] ]
- ]
- [
- [`in_addr`,
- `in6_addr`]
- [ [link asio.reference.ip__address ip::address],
- [link asio.reference.ip__address ip::address_v4],
- [link asio.reference.ip__address ip::address_v6] ]
- ]
- [
- [`sockaddr_in`,
- `sockaddr_in6`]
- [ For TCP: [link asio.reference.ip__tcp.endpoint ip::tcp::endpoint]
-
- For UDP: [link asio.reference.ip__udp.endpoint ip::udp::endpoint]
-
- [link asio.reference.ip__basic_endpoint ip::basic_endpoint] ]
- ]
- [
- [`accept()`]
- [ For TCP: [link asio.reference.basic_socket_acceptor.accept ip::tcp::acceptor::accept()]
-
- [link asio.reference.basic_socket_acceptor.accept basic_socket_acceptor::accept()] ]
- ]
- [
- [`bind()`]
- [ For TCP: [link asio.reference.basic_socket.bind ip::tcp::acceptor::bind()],
- [link asio.reference.basic_socket.bind ip::tcp::socket::bind()]
-
- For UDP: [link asio.reference.basic_socket.bind ip::udp::socket::bind()]
-
- [link asio.reference.basic_socket.bind basic_socket::bind()] ]
- ]
- [
- [`close()`]
- [ For TCP: [link asio.reference.basic_socket.close ip::tcp::acceptor::close()],
- [link asio.reference.basic_socket.close ip::tcp::socket::close()]
-
- For UDP: [link asio.reference.basic_socket.close ip::udp::socket::close()]
-
- [link asio.reference.basic_socket.close basic_socket::close()] ]
- ]
- [
- [`connect()`]
- [ For TCP: [link asio.reference.basic_socket.connect ip::tcp::socket::connect()]
-
- For UDP: [link asio.reference.basic_socket.connect ip::udp::socket::connect()]
-
- [link asio.reference.basic_socket.connect basic_socket::connect()] ]
- ]
- [
- [`getaddrinfo()`,
- `gethostbyaddr()`,
- `gethostbyname()`,
- `getnameinfo()`,
- `getservbyname()`,
- `getservbyport()`]
- [ For TCP: [link asio.reference.ip__basic_resolver.resolve ip::tcp::resolver::resolve()],
- [link asio.reference.ip__basic_resolver.async_resolve ip::tcp::resolver::async_resolve()]
-
- For UDP: [link asio.reference.ip__basic_resolver.resolve ip::udp::resolver::resolve()],
- [link asio.reference.ip__basic_resolver.async_resolve ip::udp::resolver::async_resolve()]
-
- [link asio.reference.ip__basic_resolver.resolve ip::basic_resolver::resolve()],
- [link asio.reference.ip__basic_resolver.async_resolve ip::basic_resolver::async_resolve()] ]
- ]
- [
- [`gethostname()`]
- [ [link asio.reference.ip__host_name ip::host_name()] ]
- ]
- [
- [`getpeername()`]
- [ For TCP: [link asio.reference.basic_socket.remote_endpoint ip::tcp::socket::remote_endpoint()]
-
- For UDP: [link asio.reference.basic_socket.remote_endpoint ip::udp::socket::remote_endpoint()]
-
- [link asio.reference.basic_socket.remote_endpoint basic_socket::remote_endpoint()] ]
- ]
- [
- [`getsockname()`]
- [ For TCP: [link asio.reference.basic_socket.local_endpoint ip::tcp::acceptor::local_endpoint()],
- [link asio.reference.basic_socket.local_endpoint ip::tcp::socket::local_endpoint()]
-
- For UDP: [link asio.reference.basic_socket.local_endpoint ip::udp::socket::local_endpoint()]
-
- [link asio.reference.basic_socket.local_endpoint basic_socket::local_endpoint()] ]
- ]
- [
- [`getsockopt()`]
- [ For TCP: [link asio.reference.basic_socket.get_option ip::tcp::acceptor::get_option()],
- [link asio.reference.basic_socket.get_option ip::tcp::socket::get_option()]
-
- For UDP: [link asio.reference.basic_socket.get_option ip::udp::socket::get_option()]
-
- [link asio.reference.basic_socket.get_option basic_socket::get_option()] ]
- ]
- [
- [`inet_addr()`,
- `inet_aton()`,
- `inet_pton()`]
- [ [link asio.reference.ip__address.from_string ip::address::from_string()],
- [link asio.reference.ip__address.from_string ip::address_v4::from_string()],
- [link asio.reference.ip__address.from_string ip_address_v6::from_string()] ]
- ]
- [
- [`inet_ntoa()`,
- `inet_ntop()`]
- [ [link asio.reference.ip__address.to_string ip::address::to_string()],
- [link asio.reference.ip__address.to_string ip::address_v4::to_string()],
- [link asio.reference.ip__address.to_string ip_address_v6::to_string()] ]
- ]
- [
- [`ioctl()`]
- [ For TCP: [link asio.reference.basic_socket.io_control ip::tcp::socket::io_control()]
-
- For UDP: [link asio.reference.basic_socket.io_control ip::udp::socket::io_control()]
-
- [link asio.reference.basic_socket.io_control basic_socket::io_control()] ]
- ]
- [
- [`listen()`]
- [ For TCP: [link asio.reference.basic_socket_acceptor.listen ip::tcp::acceptor::listen()]
-
- [link asio.reference.basic_socket_acceptor.listen basic_socket_acceptor::listen()] ]
- ]
- [
- [`poll()`,
- `select()`,
- `pselect()`]
- [ [link asio.reference.io_context.run io_context::run()],
- [link asio.reference.io_context.run_one io_context::run_one()],
- [link asio.reference.io_context.poll io_context::poll()],
- [link asio.reference.io_context.poll_one io_context::poll_one()]
-
- Note: in conjunction with asynchronous operations. ]
- ]
- [
- [`readv()`,
- `recv()`,
- `read()`]
- [ For TCP: [link asio.reference.basic_stream_socket.read_some ip::tcp::socket::read_some()],
- [link asio.reference.basic_stream_socket.async_read_some ip::tcp::socket::async_read_some()],
- [link asio.reference.basic_stream_socket.receive ip::tcp::socket::receive()],
- [link asio.reference.basic_stream_socket.async_receive ip::tcp::socket::async_receive()]
-
- For UDP: [link asio.reference.basic_datagram_socket.receive ip::udp::socket::receive()],
- [link asio.reference.basic_datagram_socket.async_receive ip::udp::socket::async_receive()]
-
- [link asio.reference.basic_stream_socket.read_some basic_stream_socket::read_some()],
- [link asio.reference.basic_stream_socket.async_read_some basic_stream_socket::async_read_some()],
- [link asio.reference.basic_stream_socket.receive basic_stream_socket::receive()],
- [link asio.reference.basic_stream_socket.async_receive basic_stream_socket::async_receive()],
- [link asio.reference.basic_datagram_socket.receive basic_datagram_socket::receive()],
- [link asio.reference.basic_datagram_socket.async_receive basic_datagram_socket::async_receive()] ]
- ]
- [
- [`recvfrom()`]
- [ For UDP: [link asio.reference.basic_datagram_socket.receive_from ip::udp::socket::receive_from()],
- [link asio.reference.basic_datagram_socket.async_receive_from ip::udp::socket::async_receive_from()]
-
- [link asio.reference.basic_datagram_socket.receive_from basic_datagram_socket::receive_from()],
- [link asio.reference.basic_datagram_socket.async_receive_from basic_datagram_socket::async_receive_from()] ]
- ]
- [
- [`send()`,
- `write()`,
- `writev()`]
- [ For TCP: [link asio.reference.basic_stream_socket.write_some ip::tcp::socket::write_some()],
- [link asio.reference.basic_stream_socket.async_write_some ip::tcp::socket::async_write_some()],
- [link asio.reference.basic_stream_socket.send ip::tcp::socket::send()],
- [link asio.reference.basic_stream_socket.async_send ip::tcp::socket::async_send()]
-
- For UDP: [link asio.reference.basic_datagram_socket.send ip::udp::socket::send()],
- [link asio.reference.basic_datagram_socket.async_send ip::udp::socket::async_send()]
-
- [link asio.reference.basic_stream_socket.write_some basic_stream_socket::write_some()],
- [link asio.reference.basic_stream_socket.async_write_some basic_stream_socket::async_write_some()],
- [link asio.reference.basic_stream_socket.send basic_stream_socket::send()],
- [link asio.reference.basic_stream_socket.async_send basic_stream_socket::async_send()],
- [link asio.reference.basic_datagram_socket.send basic_datagram_socket::send()],
- [link asio.reference.basic_datagram_socket.async_send basic_datagram_socket::async_send()] ]
- ]
- [
- [`sendto()`]
- [ For UDP: [link asio.reference.basic_datagram_socket.send_to ip::udp::socket::send_to()],
- [link asio.reference.basic_datagram_socket.async_send_to ip::udp::socket::async_send_to()]
-
- [link asio.reference.basic_datagram_socket.send_to basic_datagram_socket::send_to()],
- [link asio.reference.basic_datagram_socket.async_send_to basic_datagram_socket::async_send_to()] ]
- ]
- [
- [`setsockopt()`]
- [ For TCP: [link asio.reference.basic_socket.set_option ip::tcp::acceptor::set_option()],
- [link asio.reference.basic_socket.set_option ip::tcp::socket::set_option()]
-
- For UDP: [link asio.reference.basic_socket.set_option ip::udp::socket::set_option()]
-
- [link asio.reference.basic_socket.set_option basic_socket::set_option()] ]
- ]
- [
- [`shutdown()`]
- [ For TCP: [link asio.reference.basic_socket.shutdown ip::tcp::socket::shutdown()]
-
- For UDP: [link asio.reference.basic_socket.shutdown ip::udp::socket::shutdown()]
-
- [link asio.reference.basic_socket.shutdown basic_socket::shutdown()] ]
- ]
- [
- [`sockatmark()`]
- [ For TCP: [link asio.reference.basic_socket.at_mark ip::tcp::socket::at_mark()]
-
- [link asio.reference.basic_socket.at_mark basic_socket::at_mark()] ]
- ]
- [
- [`socket()`]
- [ For TCP: [link asio.reference.basic_socket.open ip::tcp::acceptor::open()],
- [link asio.reference.basic_socket.open ip::tcp::socket::open()]
-
- For UDP: [link asio.reference.basic_socket.open ip::udp::socket::open()]
-
- [link asio.reference.basic_socket.open basic_socket::open()] ]
- ]
- [
- [`socketpair()`]
- [ [link asio.reference.local__connect_pair local::connect_pair()]
-
- Note: POSIX operating systems only. ]
- ]
-]
-
-[endsect]
diff --git a/3rdparty/asio/src/doc/overview/buffers.qbk b/3rdparty/asio/src/doc/overview/buffers.qbk
deleted file mode 100644
index bd8760d458f..00000000000
--- a/3rdparty/asio/src/doc/overview/buffers.qbk
+++ /dev/null
@@ -1,163 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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::vector` 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.data 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]
diff --git a/3rdparty/asio/src/doc/overview/coroutine.qbk b/3rdparty/asio/src/doc/overview/coroutine.qbk
deleted file mode 100644
index 67453674eae..00000000000
--- a/3rdparty/asio/src/doc/overview/coroutine.qbk
+++ /dev/null
@@ -1,51 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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]
diff --git a/3rdparty/asio/src/doc/overview/cpp2011.qbk b/3rdparty/asio/src/doc/overview/cpp2011.qbk
deleted file mode 100644
index fa9e6622b67..00000000000
--- a/3rdparty/asio/src/doc/overview/cpp2011.qbk
+++ /dev/null
@@ -1,275 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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_;
- tcp::socket socket_;
- ...
- void handle_accept(error_code ec)
- {
- if (!ec)
- std::make_shared<connection>(std::move(socket_))->go();
- acceptor_.async_accept(socket_, ...);
- }
- ...
- };
-
-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]
-
-As an optimisation, user-defined completion handlers may provide move
-constructors, and Asio's implementation will use a handler's move constructor
-in preference to its copy constructor. In certain circumstances, Asio may be
-able to eliminate all calls to a handler's copy constructor. However, handler
-types are still 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
- {
- shared_ptr<tcp::socket> socket;
- shared_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]
diff --git a/3rdparty/asio/src/doc/overview/handler_tracking.qbk b/3rdparty/asio/src/doc/overview/handler_tracking.qbk
deleted file mode 100644
index 3c2635254b5..00000000000
--- a/3rdparty/asio/src/doc/overview/handler_tracking.qbk
+++ /dev/null
@@ -1,102 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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:handler_tracking Handler Tracking]
-
-To aid in debugging asynchronous programs, Asio provides support for handler
-tracking. When enabled by defining `ASIO_ENABLE_HANDLER_TRACKING`, Asio
-writes debugging output to the standard error stream. The output records
-asynchronous operations and the relationships between their handlers.
-
-[teletype]
-This feature is useful when debugging and you need to know how your
-asynchronous operations are chained together, or what the pending asynchronous
-operations are. As an illustration, here is the output when you run the HTTP
-Server example, handle a single request, then shut down via Ctrl+C:
-
- @asio|1298160085.070638|0*1|signal_set@0x7fff50528f40.async_wait
- @asio|1298160085.070888|0*2|socket@0x7fff50528f60.async_accept
- @asio|1298160085.070913|0|resolver@0x7fff50528e28.cancel
- @asio|1298160118.075438|>2|ec=asio.system:0
- @asio|1298160118.075472|2*3|socket@0xb39048.async_receive
- @asio|1298160118.075507|2*4|socket@0x7fff50528f60.async_accept
- @asio|1298160118.075527|<2|
- @asio|1298160118.075540|>3|ec=asio.system:0,bytes_transferred=122
- @asio|1298160118.075731|3*5|socket@0xb39048.async_send
- @asio|1298160118.075778|<3|
- @asio|1298160118.075793|>5|ec=asio.system:0,bytes_transferred=156
- @asio|1298160118.075831|5|socket@0xb39048.close
- @asio|1298160118.075855|<5|
- @asio|1298160122.827317|>1|ec=asio.system:0,signal_number=2
- @asio|1298160122.827333|1|socket@0x7fff50528f60.close
- @asio|1298160122.827359|<1|
- @asio|1298160122.827370|>4|ec=asio.system:125
- @asio|1298160122.827378|<4|
- @asio|1298160122.827394|0|signal_set@0x7fff50528f40.cancel
-
-Each line is of the form:
-
- <tag>|<timestamp>|<action>|<description>
-
-The `<tag>` is always `@asio`, and is used to identify and extract the handler
-tracking messages from the program output.
-
-The `<timestamp>` is seconds and microseconds from 1 Jan 1970 UTC.
-
-The `<action>` takes one of the following forms:
-
-[variablelist
- [
- [>n]
- [The program entered the handler number `n`. The `<description>` shows the
- arguments to the handler.]
- ]
- [
- [<n]
- [The program left handler number `n`.]
- ]
- [
- [!n]
- [The program left handler number n due to an exception.]
- ]
- [
- [~n]
- [The handler number `n` was destroyed without having been invoked. This is
- usually the case for any unfinished asynchronous operations when the
- `io_context` is destroyed.]
- ]
- [
- [n*m]
- [The handler number `n` created a new asynchronous operation with completion
- handler number `m`. The `<description>` shows what asynchronous operation
- was started.]
- ]
- [
- [n]
- [The handler number n performed some other operation. The `<description>`
- shows what function was called. Currently only `close()` and `cancel()`
- operations are logged, as these may affect the state of pending
- asynchronous operations.]
- ]
-]
-
-Where the `<description>` shows a synchronous or asynchronous operation, the
-format is `<object-type>@<pointer>.<operation>`. For handler entry, it shows a
-comma-separated list of arguments and their values.
-
-As shown above, Each handler is assigned a numeric identifier. Where the
-handler tracking output shows a handler number of 0, it means that the action
-was performed outside of any handler.
-
-[heading Visual Representations]
-
-The handler tracking output may be post-processed using the included
-[^handlerviz.pl] tool to create a visual representation of the handlers
-(requires the GraphViz tool [^dot]).
-[c++]
-
-[endsect]
diff --git a/3rdparty/asio/src/doc/overview/implementation.qbk b/3rdparty/asio/src/doc/overview/implementation.qbk
deleted file mode 100644
index 34c92f013e8..00000000000
--- a/3rdparty/asio/src/doc/overview/implementation.qbk
+++ /dev/null
@@ -1,305 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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:implementation Platform-Specific Implementation Notes]
-
-This section lists platform-specific implementation details, such as the
-default demultiplexing mechanism, the number of threads created internally, and
-when threads are created.
-
-
-[heading Linux Kernel 2.4]
-
-Demultiplexing mechanism:
-
-* Uses `select` for demultiplexing. This means that the number of file
-descriptors in the process cannot be permitted to exceed `FD_SETSIZE`.
-
-Threads:
-
-* Demultiplexing using `select` is performed in one of the threads that calls
-`io_context::run()`, `io_context::run_one()`, `io_context::poll()` or
-`io_context::poll_one()`.
-
-* An additional thread per `io_context` is used to emulate asynchronous host
-resolution. This thread is created on the first call to either
-`ip::tcp::resolver::async_resolve()` or `ip::udp::resolver::async_resolve()`.
-
-Scatter-Gather:
-
-* At most `min(64,IOV_MAX)` buffers may be transferred in a single operation.
-
-[heading Linux Kernel 2.6]
-
-Demultiplexing mechanism:
-
-* Uses `epoll` for demultiplexing.
-
-Threads:
-
-* Demultiplexing using `epoll` is performed in one of the threads that calls
-`io_context::run()`, `io_context::run_one()`, `io_context::poll()` or
-`io_context::poll_one()`.
-
-* An additional thread per `io_context` is used to emulate asynchronous host
-resolution. This thread is created on the first call to either
-`ip::tcp::resolver::async_resolve()` or `ip::udp::resolver::async_resolve()`.
-
-Scatter-Gather:
-
-* At most `min(64,IOV_MAX)` buffers may be transferred in a single operation.
-
-
-[heading Solaris]
-
-Demultiplexing mechanism:
-
-* Uses [^/dev/poll] for demultiplexing.
-
-Threads:
-
-* Demultiplexing using [^/dev/poll] is performed in one of the threads that
-calls `io_context::run()`, `io_context::run_one()`, `io_context::poll()` or
-`io_context::poll_one()`.
-
-* An additional thread per `io_context` is used to emulate asynchronous host
-resolution. This thread is created on the first call to either
-`ip::tcp::resolver::async_resolve()` or `ip::udp::resolver::async_resolve()`.
-
-Scatter-Gather:
-
-* At most `min(64,IOV_MAX)` buffers may be transferred in a single operation.
-
-
-[heading QNX Neutrino]
-
-Demultiplexing mechanism:
-
-* Uses `select` for demultiplexing. This means that the number of file
-descriptors in the process cannot be permitted to exceed `FD_SETSIZE`.
-
-Threads:
-
-* Demultiplexing using `select` is performed in one of the threads that calls
-`io_context::run()`, `io_context::run_one()`, `io_context::poll()` or
-`io_context::poll_one()`.
-
-* An additional thread per `io_context` is used to emulate asynchronous host
-resolution. This thread is created on the first call to either
-`ip::tcp::resolver::async_resolve()` or `ip::udp::resolver::async_resolve()`.
-
-Scatter-Gather:
-
-* At most `min(64,IOV_MAX)` buffers may be transferred in a single operation.
-
-
-[heading Mac OS X]
-
-Demultiplexing mechanism:
-
-* Uses `kqueue` for demultiplexing.
-
-Threads:
-
-* Demultiplexing using `kqueue` is performed in one of the threads that calls
-`io_context::run()`, `io_context::run_one()`, `io_context::poll()` or
-`io_context::poll_one()`.
-
-* An additional thread per `io_context` is used to emulate asynchronous host
-resolution. This thread is created on the first call to either
-`ip::tcp::resolver::async_resolve()` or `ip::udp::resolver::async_resolve()`.
-
-Scatter-Gather:
-
-* At most `min(64,IOV_MAX)` buffers may be transferred in a single operation.
-
-
-[heading FreeBSD]
-
-Demultiplexing mechanism:
-
-* Uses `kqueue` for demultiplexing.
-
-Threads:
-
-* Demultiplexing using `kqueue` is performed in one of the threads that calls
-`io_context::run()`, `io_context::run_one()`, `io_context::poll()` or
-`io_context::poll_one()`.
-
-* An additional thread per `io_context` is used to emulate asynchronous host
-resolution. This thread is created on the first call to either
-`ip::tcp::resolver::async_resolve()` or `ip::udp::resolver::async_resolve()`.
-
-Scatter-Gather:
-
-* At most `min(64,IOV_MAX)` buffers may be transferred in a single operation.
-
-
-[heading AIX]
-
-Demultiplexing mechanism:
-
-* Uses `select` for demultiplexing. This means that the number of file
-descriptors in the process cannot be permitted to exceed `FD_SETSIZE`.
-
-Threads:
-
-* Demultiplexing using `select` is performed in one of the threads that calls
-`io_context::run()`, `io_context::run_one()`, `io_context::poll()` or
-`io_context::poll_one()`.
-
-* An additional thread per `io_context` is used to emulate asynchronous host
-resolution. This thread is created on the first call to either
-`ip::tcp::resolver::async_resolve()` or `ip::udp::resolver::async_resolve()`.
-
-Scatter-Gather:
-
-* At most `min(64,IOV_MAX)` buffers may be transferred in a single operation.
-
-
-[heading HP-UX]
-
-Demultiplexing mechanism:
-
-* Uses `select` for demultiplexing. This means that the number of file
-descriptors in the process cannot be permitted to exceed `FD_SETSIZE`.
-
-Threads:
-
-* Demultiplexing using `select` is performed in one of the threads that calls
-`io_context::run()`, `io_context::run_one()`, `io_context::poll()` or
-`io_context::poll_one()`.
-
-* An additional thread per `io_context` is used to emulate asynchronous host
-resolution. This thread is created on the first call to either
-`ip::tcp::resolver::async_resolve()` or `ip::udp::resolver::async_resolve()`.
-
-Scatter-Gather:
-
-* At most `min(64,IOV_MAX)` buffers may be transferred in a single operation.
-
-
-[heading Tru64]
-
-Demultiplexing mechanism:
-
-* Uses `select` for demultiplexing. This means that the number of file
-descriptors in the process cannot be permitted to exceed `FD_SETSIZE`.
-
-Threads:
-
-* Demultiplexing using `select` is performed in one of the threads that calls
-`io_context::run()`, `io_context::run_one()`, `io_context::poll()` or
-`io_context::poll_one()`.
-
-* An additional thread per `io_context` is used to emulate asynchronous host
-resolution. This thread is created on the first call to either
-`ip::tcp::resolver::async_resolve()` or `ip::udp::resolver::async_resolve()`.
-
-Scatter-Gather:
-
-* At most `min(64,IOV_MAX)` buffers may be transferred in a single operation.
-
-
-[heading Windows 95, 98 and Me]
-
-Demultiplexing mechanism:
-
-* Uses `select` for demultiplexing.
-
-Threads:
-
-* Demultiplexing using `select` is performed in one of the threads that calls
-`io_context::run()`, `io_context::run_one()`, `io_context::poll()` or
-`io_context::poll_one()`.
-
-* An additional thread per `io_context` is used to emulate asynchronous host
-resolution. This thread is created on the first call to either
-`ip::tcp::resolver::async_resolve()` or `ip::udp::resolver::async_resolve()`.
-
-Scatter-Gather:
-
-* For sockets, at most 16 buffers may be transferred in a single operation.
-
-
-[heading Windows NT, 2000, XP, 2003, Vista, 7 and 8]
-
-Demultiplexing mechanism:
-
-* Uses overlapped I/O and I/O completion ports for all asynchronous socket
-operations except for asynchronous connect.
-
-* Uses `select` for emulating asynchronous connect.
-
-Threads:
-
-* Demultiplexing using I/O completion ports is performed in all threads that call
-`io_context::run()`, `io_context::run_one()`, `io_context::poll()` or
-`io_context::poll_one()`.
-
-* An additional thread per `io_context` is used to trigger timers. This thread
-is created on construction of the first `basic_deadline_timer` or
-`basic_waitable_timer` objects.
-
-* An additional thread per `io_context` is used for the `select`
-demultiplexing. This thread is created on the first call to `async_connect()`.
-
-* An additional thread per `io_context` is used to emulate asynchronous host
-resolution. This thread is created on the first call to either
-`ip::tcp::resolver::async_resolve()` or `ip::udp::resolver::async_resolve()`.
-
-Scatter-Gather:
-
-* For sockets, at most 64 buffers may be transferred in a single operation.
-
-* For stream-oriented handles, only one buffer may be transferred in a single
-operation.
-
-[heading Windows Runtime]
-
-Asio provides limited support for the Windows Runtime. It requires that the
-language extensions be enabled. Due to the restricted facilities exposed by the
-Windows Runtime API, the support comes with the following caveats:
-
-* The core facilities such as the `io_context`, `strand`, buffers, composed
- operations, timers, etc., should all work as normal.
-
-* For sockets, only client-side TCP is supported.
-
-* Explicit binding of a client-side TCP socket is not supported.
-
-* The `cancel()` function is not supported for sockets. Asynchronous
- operations may only be cancelled by closing the socket.
-
-* Operations that use `null_buffers` are not supported.
-
-* Only `tcp::no_delay` and `socket_base::keep_alive` options are supported.
-
-* Resolvers do not support service names, only numbers. I.e. you must
- use "80" rather than "http".
-
-* Most resolver query flags have no effect.
-
-Demultiplexing mechanism:
-
-* Uses the `Windows::Networking::Sockets::StreamSocket` class to implement
- asynchronous TCP socket operations.
-
-Threads:
-
-* Event completions are delivered to the Windows thread pool and posted to the
- `io_context` for the handler to be executed.
-
-* An additional thread per `io_context` is used to trigger timers. This thread
- is created on construction of the first timer objects.
-
-Scatter-Gather:
-
-* For sockets, at most one buffer may be transferred in a single operation.
-
-
-[endsect]
diff --git a/3rdparty/asio/src/doc/overview/iostreams.qbk b/3rdparty/asio/src/doc/overview/iostreams.qbk
deleted file mode 100644
index f738f9edec5..00000000000
--- a/3rdparty/asio/src/doc/overview/iostreams.qbk
+++ /dev/null
@@ -1,72 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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:iostreams Socket Iostreams]
-
-Asio includes classes that implement iostreams on top of sockets. These hide
-away the complexities associated with endpoint resolution, protocol
-independence, etc. To create a connection one might simply write:
-
- ip::tcp::iostream stream("www.boost.org", "http");
- if (!stream)
- {
- // Can't connect.
- }
-
-The iostream class can also be used in conjunction with an acceptor to create
-simple servers. For example:
-
- io_context ioc;
-
- ip::tcp::endpoint endpoint(tcp::v4(), 80);
- ip::tcp::acceptor acceptor(ios, endpoint);
-
- for (;;)
- {
- ip::tcp::iostream stream;
- acceptor.accept(stream.socket());
- ...
- }
-
-Timeouts may be set by calling `expires_at()` or `expires_from_now()` to
-establish a deadline. Any socket operations that occur past the deadline will
-put the iostream into a "bad" state.
-
-For example, a simple client program like this:
-
- ip::tcp::iostream stream;
- stream.expires_from_now(boost::posix_time::seconds(60));
- stream.connect("www.boost.org", "http");
- stream << "GET /LICENSE_1_0.txt HTTP/1.0\r\n";
- stream << "Host: www.boost.org\r\n";
- stream << "Accept: */*\r\n";
- stream << "Connection: close\r\n\r\n";
- stream.flush();
- std::cout << stream.rdbuf();
-
-will fail if all the socket operations combined take longer than 60 seconds.
-
-If an error does occur, the iostream's `error()` member function may be used to
-retrieve the error code from the most recent system call:
-
- if (!stream)
- {
- std::cout << "Error: " << stream.error().message() << "\n";
- }
-
-[heading See Also]
-
-[link asio.reference.ip__tcp.iostream ip::tcp::iostream],
-[link asio.reference.basic_socket_iostream basic_socket_iostream],
-[link asio.examples.cpp03_examples.iostreams iostreams examples].
-
-[heading Notes]
-
-These iostream templates only support `char`, not `wchar_t`, and do not perform
-any code conversion.
-
-[endsect]
diff --git a/3rdparty/asio/src/doc/overview/line_based.qbk b/3rdparty/asio/src/doc/overview/line_based.qbk
deleted file mode 100644
index df007adc3f8..00000000000
--- a/3rdparty/asio/src/doc/overview/line_based.qbk
+++ /dev/null
@@ -1,118 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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:line_based Line-Based Operations]
-
-Many commonly-used internet protocols are line-based, which means that they
-have protocol elements that are delimited by the character sequence `"\r\n"`.
-Examples include HTTP, SMTP and FTP. To more easily permit the implementation
-of line-based protocols, as well as other protocols that use delimiters, Asio
-includes the functions `read_until()` and `async_read_until()`.
-
-The following example illustrates the use of `async_read_until()` in an HTTP
-server, to receive the first line of an HTTP request from a client:
-
- class http_connection
- {
- ...
-
- void start()
- {
- asio::async_read_until(socket_, data_, "\r\n",
- boost::bind(&http_connection::handle_request_line, this, _1));
- }
-
- void handle_request_line(asio::error_code ec)
- {
- if (!ec)
- {
- std::string method, uri, version;
- char sp1, sp2, cr, lf;
- std::istream is(&data_);
- is.unsetf(std::ios_base::skipws);
- is >> method >> sp1 >> uri >> sp2 >> version >> cr >> lf;
- ...
- }
- }
-
- ...
-
- asio::ip::tcp::socket socket_;
- asio::streambuf data_;
- };
-
-The `streambuf` data member serves as a place to store the data that has been
-read from the socket before it is searched for the delimiter. It is important
-to remember that there may be additional data ['after] the delimiter. This
-surplus data should be left in the `streambuf` so that it may be inspected by a
-subsequent call to `read_until()` or `async_read_until()`.
-
-The delimiters may be specified as a single `char`, a `std::string` or a
-`boost::regex`. The `read_until()` and `async_read_until()` functions also
-include overloads that accept a user-defined function object called a match
-condition. For example, to read data into a streambuf until whitespace is
-encountered:
-
- typedef asio::buffers_iterator<
- asio::streambuf::const_buffers_type> iterator;
-
- std::pair<iterator, bool>
- match_whitespace(iterator begin, iterator end)
- {
- iterator i = begin;
- while (i != end)
- if (std::isspace(*i++))
- return std::make_pair(i, true);
- return std::make_pair(i, false);
- }
- ...
- asio::streambuf b;
- asio::read_until(s, b, match_whitespace);
-
-To read data into a streambuf until a matching character is found:
-
- class match_char
- {
- public:
- explicit match_char(char c) : c_(c) {}
-
- template <typename Iterator>
- std::pair<Iterator, bool> operator()(
- Iterator begin, Iterator end) const
- {
- Iterator i = begin;
- while (i != end)
- if (c_ == *i++)
- return std::make_pair(i, true);
- return std::make_pair(i, false);
- }
-
- private:
- char c_;
- };
-
- namespace asio {
- template <> struct is_match_condition<match_char>
- : public boost::true_type {};
- } // namespace asio
- ...
- asio::streambuf b;
- asio::read_until(s, b, match_char('a'));
-
-The `is_match_condition<>` type trait automatically evaluates to true for
-functions, and for function objects with a nested `result_type` typedef. For
-other types the trait must be explicitly specialised, as shown above.
-
-[heading See Also]
-
-[link asio.reference.async_read_until async_read_until()],
-[link asio.reference.is_match_condition is_match_condition],
-[link asio.reference.read_until read_until()],
-[link asio.reference.streambuf streambuf],
-[link asio.examples.cpp03_examples.http_client HTTP client example].
-
-[endsect]
diff --git a/3rdparty/asio/src/doc/overview/other_protocols.qbk b/3rdparty/asio/src/doc/overview/other_protocols.qbk
deleted file mode 100644
index 9a6fe077ea1..00000000000
--- a/3rdparty/asio/src/doc/overview/other_protocols.qbk
+++ /dev/null
@@ -1,94 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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:other_protocols Support for Other Protocols]
-
-Support for other socket protocols (such as Bluetooth or IRCOMM sockets) can be
-added by implementing the [link asio.reference.Protocol protocol type
-requirements]. However, in many cases these protocols may also be used with
-Asio's generic protocol support. For this, Asio provides the following four
-classes:
-
-* [link asio.reference.generic__datagram_protocol `generic::datagram_protocol`]
-* [link asio.reference.generic__raw_protocol `generic::raw_protocol`]
-* [link asio.reference.generic__seq_packet_protocol `generic::seq_packet_protocol`]
-* [link asio.reference.generic__stream_protocol `generic::stream_protocol`]
-
-These classes implement the [link asio.reference.Protocol 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. For example:
-
- asio::generic::stream_protocol::socket my_socket(my_io_context);
- my_socket.open(asio::generic::stream_protocol(AF_INET, IPPROTO_TCP));
- ...
-
-An endpoint class template, [link asio.reference.generic__basic_endpoint
-`asio::generic::basic_endpoint`], is included to support these protocol
-classes. This endpoint can hold any other endpoint type, provided its native
-representation fits into a `sockaddr_storage` object. This class will also
-convert from other types that implement the [link asio.reference.Endpoint
-endpoint] type requirements:
-
- asio::ip::tcp::endpoint my_endpoint1 = ...;
- asio::generic::stream_protocol::endpoint my_endpoint2(my_endpoint1);
-
-The conversion is implicit, so as to support the following use cases:
-
- asio::generic::stream_protocol::socket my_socket(my_io_context);
- asio::ip::tcp::endpoint my_endpoint = ...;
- my_socket.connect(my_endpoint);
-
-[heading C++11 Move Construction]
-
-When using C++11, it is 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 my_socket1(my_io_context);
- ...
- Protocol2::socket my_socket2(std::move(my_socket1));
-
-For example, one possible conversion is from a TCP socket to a generic
-stream-oriented socket:
-
- asio::ip::tcp::socket my_socket1(my_io_context);
- ...
- asio::generic::stream_protocol::socket my_socket2(std::move(my_socket1));
-
-These conversions are also available for move-assignment.
-
-These conversions are not limited to the above 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.
-
-[heading Accepting Generic Sockets]
-
-As a convenience, a socket acceptor's `accept()` and `async_accept()` functions
-can directly accept into a different protocol's socket type, provided the
-corresponding protocol conversion is valid. For example, the following is
-supported because the protocol `asio::ip::tcp` is convertible to
-`asio::generic::stream_protocol`:
-
- asio::ip::tcp::acceptor my_acceptor(my_io_context);
- ...
- asio::generic::stream_protocol::socket my_socket(my_io_context);
- my_acceptor.accept(my_socket);
-
-[heading See Also]
-
-[link asio.reference.generic__datagram_protocol `generic::datagram_protocol`],
-[link asio.reference.generic__raw_protocol `generic::raw_protocol`],
-[link asio.reference.generic__seq_packet_protocol `generic::seq_packet_protocol`],
-[link asio.reference.generic__stream_protocol `generic::stream_protocol`],
-[link asio.reference.Protocol protocol type requirements].
-
-[endsect]
diff --git a/3rdparty/asio/src/doc/overview/posix.qbk b/3rdparty/asio/src/doc/overview/posix.qbk
deleted file mode 100644
index 19c91783e64..00000000000
--- a/3rdparty/asio/src/doc/overview/posix.qbk
+++ /dev/null
@@ -1,152 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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:posix POSIX-Specific Functionality]
-
-[link asio.overview.posix.local UNIX Domain Sockets]
-
-[link asio.overview.posix.stream_descriptor Stream-Oriented File Descriptors]
-
-[link asio.overview.posix.fork Fork]
-
-[section:local UNIX Domain Sockets]
-
-Asio provides basic support UNIX domain sockets (also known as local sockets).
-The simplest use involves creating a pair of connected sockets. The following
-code:
-
- local::stream_protocol::socket socket1(my_io_context);
- local::stream_protocol::socket socket2(my_io_context);
- local::connect_pair(socket1, socket2);
-
-will create a pair of stream-oriented sockets. To do the same for
-datagram-oriented sockets, use:
-
- local::datagram_protocol::socket socket1(my_io_context);
- local::datagram_protocol::socket socket2(my_io_context);
- local::connect_pair(socket1, socket2);
-
-A UNIX domain socket server may be created by binding an acceptor to an
-endpoint, in much the same way as one does for a TCP server:
-
- ::unlink("/tmp/foobar"); // Remove previous binding.
- local::stream_protocol::endpoint ep("/tmp/foobar");
- local::stream_protocol::acceptor acceptor(my_io_context, ep);
- local::stream_protocol::socket socket(my_io_context);
- acceptor.accept(socket);
-
-A client that connects to this server might look like:
-
- local::stream_protocol::endpoint ep("/tmp/foobar");
- local::stream_protocol::socket socket(my_io_context);
- socket.connect(ep);
-
-Transmission of file descriptors or credentials across UNIX domain sockets is
-not directly supported within Asio, but may be achieved by accessing the
-socket's underlying descriptor using the [link
-asio.reference.basic_socket.native_handle native_handle()] member function.
-
-[heading See Also]
-
-[link asio.reference.local__connect_pair local::connect_pair],
-[link asio.reference.local__datagram_protocol local::datagram_protocol],
-[link asio.reference.local__datagram_protocol.endpoint local::datagram_protocol::endpoint],
-[link asio.reference.local__datagram_protocol.socket local::datagram_protocol::socket],
-[link asio.reference.local__stream_protocol local::stream_protocol],
-[link asio.reference.local__stream_protocol.acceptor local::stream_protocol::acceptor],
-[link asio.reference.local__stream_protocol.endpoint local::stream_protocol::endpoint],
-[link asio.reference.local__stream_protocol.iostream local::stream_protocol::iostream],
-[link asio.reference.local__stream_protocol.socket local::stream_protocol::socket],
-[link asio.examples.cpp03_examples.unix_domain_sockets UNIX domain sockets examples].
-
-[heading Notes]
-
-UNIX domain sockets are only available at compile time if supported by the
-target operating system. A program may test for the macro
-`ASIO_HAS_LOCAL_SOCKETS` to determine whether they are supported.
-
-[endsect]
-
-[section:stream_descriptor Stream-Oriented File Descriptors]
-
-Asio includes classes added to permit synchronous and asynchronous read and
-write operations to be performed on POSIX file descriptors, such as pipes,
-standard input and output, and various devices.
-
-These classes also provide limited support for regular files. This support
-assumes that the underlying read and write operations provided by the operating
-system never fail with `EAGAIN` or `EWOULDBLOCK`. (This assumption normally
-holds for buffered file I/O.) Synchronous and asynchronous read and write
-operations on file descriptors will succeed but the I/O will always be
-performed immediately. Wait operations, and operations involving
-`asio::null_buffers`, are not portably supported.
-
-For example, to perform read and write operations on standard input
-and output, the following objects may be created:
-
- posix::stream_descriptor in(my_io_context, ::dup(STDIN_FILENO));
- posix::stream_descriptor out(my_io_context, ::dup(STDOUT_FILENO));
-
-These are then used as synchronous or asynchronous read and write streams. This
-means the objects can be used with any of the [link asio.reference.read
-read()], [link asio.reference.async_read async_read()], [link
-asio.reference.write write()], [link asio.reference.async_write async_write()],
-[link asio.reference.read_until read_until()] or [link
-asio.reference.async_read_until async_read_until()] free functions.
-
-[heading See Also]
-
-[link asio.reference.posix__stream_descriptor posix::stream_descriptor],
-[link asio.examples.cpp03_examples.chat Chat example (C++03)],
-[link asio.examples.cpp11_examples.chat Chat example (C++11)].
-
-[heading Notes]
-
-POSIX stream descriptors are only available at compile time if supported by the
-target operating system. A program may test for the macro
-`ASIO_HAS_POSIX_STREAM_DESCRIPTOR` to determine whether they are supported.
-
-[endsect]
-
-[section:fork Fork]
-
-Asio supports programs that utilise the `fork()` system call. Provided the
-program calls `io_context.notify_fork()` at the appropriate times, Asio will
-recreate any internal file descriptors (such as the "self-pipe trick"
-descriptor used for waking up a reactor). The notification is usually performed
-as follows:
-
- io_context_.notify_fork(asio::io_context::fork_prepare);
- if (fork() == 0)
- {
- io_context_.notify_fork(asio::io_context::fork_child);
- ...
- }
- else
- {
- io_context_.notify_fork(asio::io_context::fork_parent);
- ...
- }
-
-User-defined services can also be made fork-aware by overriding the
-`io_context::service::notify_fork()` virtual function.
-
-Note that any file descriptors accessible via Asio's public API (e.g. the
-descriptors underlying `basic_socket<>`, `posix::stream_descriptor`, etc.) are
-not altered during a fork. It is the program's responsibility to manage these
-as required.
-
-[heading See Also]
-
-[link asio.reference.io_context.notify_fork io_context::notify_fork()],
-[link asio.reference.io_context.fork_event io_context::fork_event],
-[link asio.reference.execution_context__service.notify_fork io_context::service::notify_fork()],
-[link asio.examples.cpp03_examples.fork Fork examples].
-
-[endsect]
-
-[endsect]
diff --git a/3rdparty/asio/src/doc/overview/proactor.dot b/3rdparty/asio/src/doc/overview/proactor.dot
deleted file mode 100644
index 871723408b9..00000000000
--- a/3rdparty/asio/src/doc/overview/proactor.dot
+++ /dev/null
@@ -1,100 +0,0 @@
-digraph g
-{
- edge
- [
- fontname="Helvetica",
- fontsize=10,
- labelfontname="Helvetica",
- labelfontsize=10
- ];
-
- node
- [
- fontname="Helvetica",
- fontsize=10,
- shape=record
- ];
-
- initiator
- [
- label="Initiator"
- ];
-
- async_processor
- [
- label="Asynchronous\nOperation Processor"
- ];
-
- async_op
- [
- label="Asynchronous\nOperation"
- ];
-
- completion_queue
- [
- label="Completion\nEvent Queue"
- ];
-
- async_event_demuxer
- [
- label="Asynchronous\nEvent Demultiplexer"
- ];
-
- proactor
- [
- label="Proactor"
- ];
-
- handler
- [
- label="Completion\nHandler"
- ];
-
- initiator -> async_processor
- [
- label="uses",
- style="dashed"
- ];
-
- initiator -> async_op
- [
- label="starts",
- style="dashed"
- ];
-
- initiator -> handler
- [
- label="creates",
- style="dashed"
- ];
-
- async_processor -> async_op
- [
- label="executes",
- style="dashed"
- ];
-
- async_processor -> completion_queue
- [
- label="enqueues",
- style="dashed"
- ];
-
- async_op -> handler;
-
- async_event_demuxer -> completion_queue
- [
- label="dequeues",
- style="dashed"
- ];
-
- proactor -> async_event_demuxer
- [
- ];
-
- proactor -> handler
- [
- label="demultiplexes\n& dispatches"
- style="dashed"
- ];
-}
diff --git a/3rdparty/asio/src/doc/overview/proactor.png b/3rdparty/asio/src/doc/overview/proactor.png
deleted file mode 100644
index a0653b0106c..00000000000
--- a/3rdparty/asio/src/doc/overview/proactor.png
+++ /dev/null
Binary files differ
diff --git a/3rdparty/asio/src/doc/overview/protocols.qbk b/3rdparty/asio/src/doc/overview/protocols.qbk
deleted file mode 100644
index eed070c7511..00000000000
--- a/3rdparty/asio/src/doc/overview/protocols.qbk
+++ /dev/null
@@ -1,149 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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:protocols TCP, UDP and ICMP]
-
-Asio provides off-the-shelf support for the internet protocols TCP, UDP and
-ICMP.
-
-[heading TCP Clients]
-
-Hostname resolution is performed using a resolver, where host and service names
-are looked up and converted into one or more endpoints:
-
- ip::tcp::resolver resolver(my_io_context);
- ip::tcp::resolver::query query("www.boost.org", "http");
- ip::tcp::resolver::iterator iter = resolver.resolve(query);
- ip::tcp::resolver::iterator end; // End marker.
- while (iter != end)
- {
- ip::tcp::endpoint endpoint = *iter++;
- std::cout << endpoint << std::endl;
- }
-
-The list of endpoints obtained above could contain both IPv4 and IPv6 endpoints,
-so a program should try each of them until it finds one that works. This keeps the
-client program independent of a specific IP version.
-
-To simplify the development of protocol-independent programs, TCP clients may
-establish connections using the free functions [link asio.reference.connect
-connect()] and [link asio.reference.async_connect async_connect()]. These
-operations try each endpoint in a list until the socket is successfully
-connected. For example, a single call:
-
- ip::tcp::socket socket(my_io_context);
- asio::connect(socket, resolver.resolve(query));
-
-will synchronously try all endpoints until one is successfully connected.
-Similarly, an asynchronous connect may be performed by writing:
-
- asio::async_connect(socket_, iter,
- boost::bind(&client::handle_connect, this,
- asio::placeholders::error));
-
- // ...
-
- void handle_connect(const error_code& error)
- {
- if (!error)
- {
- // Start read or write operations.
- }
- else
- {
- // Handle error.
- }
- }
-
-When a specific endpoint is available, a socket can be created and connected:
-
- ip::tcp::socket socket(my_io_context);
- socket.connect(endpoint);
-
-Data may be read from or written to a connected TCP socket using the [link
-asio.reference.basic_stream_socket.receive receive()], [link
-asio.reference.basic_stream_socket.async_receive async_receive()], [link
-asio.reference.basic_stream_socket.send send()] or [link
-asio.reference.basic_stream_socket.async_send async_send()] member functions.
-However, as these could result in [link asio.overview.core.streams short writes
-or reads], an application will typically use the following operations instead:
-[link asio.reference.read read()], [link asio.reference.async_read
-async_read()], [link asio.reference.write write()] and [link
-asio.reference.async_write async_write()].
-
-[heading TCP Servers]
-
-A program uses an acceptor to accept incoming TCP connections:
-
- ip::tcp::acceptor acceptor(my_io_context, my_endpoint);
- ...
- ip::tcp::socket socket(my_io_context);
- acceptor.accept(socket);
-
-After a socket has been successfully accepted, it may be read from or written
-to as illustrated for TCP clients above.
-
-[heading UDP]
-
-UDP hostname resolution is also performed using a resolver:
-
- ip::udp::resolver resolver(my_io_context);
- ip::udp::resolver::query query("localhost", "daytime");
- ip::udp::resolver::iterator iter = resolver.resolve(query);
- ...
-
-A UDP socket is typically bound to a local endpoint. The following code will
-create an IP version 4 UDP socket and bind it to the "any" address on port
-`12345`:
-
- ip::udp::endpoint endpoint(ip::udp::v4(), 12345);
- ip::udp::socket socket(my_io_context, endpoint);
-
-Data may be read from or written to an unconnected UDP socket using the [link
-asio.reference.basic_datagram_socket.receive_from receive_from()], [link
-asio.reference.basic_datagram_socket.async_receive_from async_receive_from()],
-[link asio.reference.basic_datagram_socket.send_to send_to()] or [link
-asio.reference.basic_datagram_socket.async_send_to async_send_to()] member
-functions. For a connected UDP socket, use the [link
-asio.reference.basic_datagram_socket.receive receive()], [link
-asio.reference.basic_datagram_socket.async_receive async_receive()], [link
-asio.reference.basic_datagram_socket.send send()] or [link
-asio.reference.basic_datagram_socket.async_send async_send()] member functions.
-
-[heading ICMP]
-
-As with TCP and UDP, ICMP hostname resolution is performed using a resolver:
-
- ip::icmp::resolver resolver(my_io_context);
- ip::icmp::resolver::query query("localhost", "");
- ip::icmp::resolver::iterator iter = resolver.resolve(query);
- ...
-
-An ICMP socket may be bound to a local endpoint. The following code will create
-an IP version 6 ICMP socket and bind it to the "any" address:
-
- ip::icmp::endpoint endpoint(ip::icmp::v6(), 0);
- ip::icmp::socket socket(my_io_context, endpoint);
-
-The port number is not used for ICMP.
-
-Data may be read from or written to an unconnected ICMP socket using the [link
-asio.reference.basic_raw_socket.receive_from receive_from()], [link
-asio.reference.basic_raw_socket.async_receive_from async_receive_from()],
-[link asio.reference.basic_raw_socket.send_to send_to()] or [link
-asio.reference.basic_raw_socket.async_send_to async_send_to()] member
-functions.
-
-[heading See Also]
-
-[link asio.reference.ip__tcp ip::tcp],
-[link asio.reference.ip__udp ip::udp],
-[link asio.reference.ip__icmp ip::icmp],
-[link asio.tutorial.tutdaytime1 daytime protocol tutorials],
-[link asio.examples.cpp03_examples.icmp ICMP ping example].
-
-[endsect]
diff --git a/3rdparty/asio/src/doc/overview/rationale.qbk b/3rdparty/asio/src/doc/overview/rationale.qbk
deleted file mode 100644
index 13491cd53d0..00000000000
--- a/3rdparty/asio/src/doc/overview/rationale.qbk
+++ /dev/null
@@ -1,54 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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:rationale Rationale]
-
-Most programs interact with the outside world in some way, whether it be via a
-file, a network, a serial cable, or the console. Sometimes, as is the case with
-networking, individual I/O operations can take a long time to complete. This
-poses particular challenges to application development.
-
-Asio provides the tools to manage these long running operations, without
-requiring programs to use concurrency models based on threads and explicit
-locking.
-
-The Asio library is intended for programmers using C++ for systems programming,
-where access to operating system functionality such as networking is often
-required. In particular, Asio addresses the following goals:
-
-* [*Portability.] The library should support a range of commonly used operating
-systems, and provide consistent behaviour across these operating systems.
-
-* [*Scalability.] The library should facilitate the development of network
-applications that scale to thousands of concurrent connections. The library
-implementation for each operating system should use the mechanism that best
-enables this scalability.
-
-* [*Efficiency.] The library should support techniques such as scatter-gather
-I/O, and allow programs to minimise data copying.
-
-* [*Model concepts from established APIs, such as BSD sockets.] The
-BSD socket API is widely implemented and understood, and is covered in much
-literature. Other programming languages often use a similar interface for
-networking APIs. As far as is reasonable, Asio should leverage existing
-practice.
-
-* [*Ease of use.] The library should provide a lower entry barrier for new
-users by taking a toolkit, rather than framework, approach. That is, it should
-try to minimise the up-front investment in time to just learning a few basic
-rules and guidelines. After that, a library user should only need to understand
-the specific functions that are being used.
-
-* [*Basis for further abstraction.] The library should permit the development
-of other libraries that provide higher levels of abstraction. For example,
-implementations of commonly used protocols such as HTTP.
-
-Although Asio started life focused primarily on networking, its concepts of
-asynchronous I/O have been extended to include other operating system resources
-such as serial ports, file descriptors, and so on.
-
-[endsect]
diff --git a/3rdparty/asio/src/doc/overview/reactor.qbk b/3rdparty/asio/src/doc/overview/reactor.qbk
deleted file mode 100644
index 468645ad4c0..00000000000
--- a/3rdparty/asio/src/doc/overview/reactor.qbk
+++ /dev/null
@@ -1,44 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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:reactor Reactor-Style Operations]
-
-Sometimes a program must be integrated with a third-party library that wants to
-perform the I/O operations itself. To facilitate this, Asio includes
-synchronous and asynchronous operations that may be used to wait for a socket
-to become ready to read, ready to write, or to have a pending error condition.
-
-As an example, to perform a non-blocking read something like the following may
-be used:
-
- ip::tcp::socket socket(my_io_context);
- ...
- socket.non_blocking(true);
- ...
- socket.async_wait(ip::tcp::socket::wait_read, read_handler);
- ...
- void read_handler(asio::error_code ec)
- {
- if (!ec)
- {
- std::vector<char> buf(socket.available());
- socket.read_some(buffer(buf));
- }
- }
-
-These operations are supported for sockets on all platforms, and for the POSIX
-stream-oriented descriptor classes.
-
-[heading See Also]
-
-[link asio.reference.basic_socket.wait basic_socket::wait()],
-[link asio.reference.basic_socket.async_wait basic_socket::async_wait()],
-[link asio.reference.basic_socket.non_blocking basic_socket::non_blocking()],
-[link asio.reference.basic_socket.native_non_blocking basic_socket::native_non_blocking()],
-[link asio.examples.cpp03_examples.nonblocking nonblocking example].
-
-[endsect]
diff --git a/3rdparty/asio/src/doc/overview/serial_ports.qbk b/3rdparty/asio/src/doc/overview/serial_ports.qbk
deleted file mode 100644
index dd049cd2fa1..00000000000
--- a/3rdparty/asio/src/doc/overview/serial_ports.qbk
+++ /dev/null
@@ -1,45 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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:serial_ports Serial Ports]
-
-Asio includes classes for creating and manipulating serial ports in a portable
-manner. For example, a serial port may be opened using:
-
- serial_port port(my_io_context, name);
-
-where name is something like `"COM1"` on Windows, and `"/dev/ttyS0"` on POSIX
-platforms.
-
-Once opened, the serial port may be used as a [link asio.overview.core.streams
-stream]. This means the objects can be used with any of the [link
-asio.reference.read read()], [link asio.reference.async_read async_read()],
-[link asio.reference.write write()], [link asio.reference.async_write
-async_write()], [link asio.reference.read_until read_until()] or [link
-asio.reference.async_read_until async_read_until()] free functions.
-
-The serial port implementation also includes option classes for configuring the
-port's baud rate, flow control type, parity, stop bits and character size.
-
-[heading See Also]
-
-[link asio.reference.serial_port serial_port],
-[link asio.reference.serial_port_base serial_port_base],
-[link asio.reference.serial_port_base__baud_rate serial_port_base::baud_rate],
-[link asio.reference.serial_port_base__flow_control serial_port_base::flow_control],
-[link asio.reference.serial_port_base__parity serial_port_base::parity],
-[link asio.reference.serial_port_base__stop_bits serial_port_base::stop_bits],
-[link asio.reference.serial_port_base__character_size serial_port_base::character_size].
-
-[heading Notes]
-
-Serial ports are available on all POSIX platforms. For Windows, serial ports
-are only available at compile time when the I/O completion port backend is used
-(which is the default). A program may test for the macro
-`ASIO_HAS_SERIAL_PORT` to determine whether they are supported.
-
-[endsect]
diff --git a/3rdparty/asio/src/doc/overview/signals.qbk b/3rdparty/asio/src/doc/overview/signals.qbk
deleted file mode 100644
index d626ead861c..00000000000
--- a/3rdparty/asio/src/doc/overview/signals.qbk
+++ /dev/null
@@ -1,44 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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:signals Signal Handling]
-
-Asio supports signal handling using a class called [link
-asio.reference.signal_set signal_set]. Programs may add one or more signals to
-the set, and then perform an `async_wait()` operation. The specified handler
-will be called when one of the signals occurs. The same signal number may be
-registered with multiple [link asio.reference.signal_set signal_set] objects,
-however the signal number must be used only with Asio.
-
- void handler(
- const asio::error_code& error,
- int signal_number)
- {
- if (!error)
- {
- // A signal occurred.
- }
- }
-
- ...
-
- // Construct a signal set registered for process termination.
- asio::signal_set signals(io_context, SIGINT, SIGTERM);
-
- // Start an asynchronous wait for one of the signals to occur.
- signals.async_wait(handler);
-
-Signal handling also works on Windows, as the Microsoft Visual C++ runtime
-library maps console events like Ctrl+C to the equivalent signal.
-
-[heading See Also]
-
-[link asio.reference.signal_set signal_set],
-[link asio.examples.cpp03_examples.http_server HTTP server example (C++03)],
-[link asio.examples.cpp11_examples.http_server HTTP server example (C++11)].
-
-[endsect]
diff --git a/3rdparty/asio/src/doc/overview/spawn.qbk b/3rdparty/asio/src/doc/overview/spawn.qbk
deleted file mode 100644
index 908d78f72ae..00000000000
--- a/3rdparty/asio/src/doc/overview/spawn.qbk
+++ /dev/null
@@ -1,102 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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:spawn Stackful Coroutines]
-
-The [link asio.reference.spawn `spawn()`] function is a high-level wrapper for
-running stackful coroutines. It is based on the Boost.Coroutine library. The
-`spawn()` function enables programs to implement asynchronous logic in a
-synchronous manner, as shown in the following example:
-
- asio::spawn(my_strand, do_echo);
-
- // ...
-
- void do_echo(asio::yield_context yield)
- {
- try
- {
- char data[128];
- for (;;)
- {
- std::size_t length =
- my_socket.async_read_some(
- asio::buffer(data), yield);
-
- asio::async_write(my_socket,
- asio::buffer(data, length), yield);
- }
- }
- catch (std::exception& e)
- {
- // ...
- }
- }
-
-The first argument to `spawn()` may be a
-[link asio.reference.io_context__strand `strand`],
-[link asio.reference.io_context `io_context`], or
-[link asio.reference.CompletionHandler completion handler].
-This argument 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 function object with signature:
-
- void coroutine(asio::yield_context yield);
-
-that specifies the code to be run as part of the coroutine. The parameter
-`yield` may be passed to an asynchronous operation in place of the completion
-handler, as in:
-
- std::size_t length =
- my_socket.async_read_some(
- asio::buffer(data), yield);
-
-This starts the asynchronous operation and suspends the coroutine. The
-coroutine will be resumed automatically when the asynchronous operation
-completes.
-
-Where an asynchronous operation's handler signature has the form:
-
- void handler(asio::error_code ec, result_type result);
-
-the initiating function returns the 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 initiating function returns `void`. As above, an error is passed back to
-the coroutine as a `system_error` exception.
-
-To collect the `error_code` from an operation, rather than have it throw an
-exception, associate the output variable with the `yield_context` as follows:
-
- asio::error_code ec;
- std::size_t length =
- my_socket.async_read_some(
- asio::buffer(data), yield[ec]);
-
-[*Note:] if `spawn()` is used with a custom completion handler of type
-`Handler`, the function object signature is actually:
-
- void coroutine(asio::basic_yield_context<Handler> yield);
-
-[heading See Also]
-
-[link asio.reference.spawn spawn],
-[link asio.reference.yield_context yield_context],
-[link asio.reference.basic_yield_context basic_yield_context],
-[link asio.examples.cpp03_examples.spawn Spawn example (C++03)],
-[link asio.examples.cpp11_examples.spawn Spawn example (C++11)],
-[link asio.overview.core.coroutine Stackless Coroutines].
-
-[endsect]
diff --git a/3rdparty/asio/src/doc/overview/ssl.qbk b/3rdparty/asio/src/doc/overview/ssl.qbk
deleted file mode 100644
index e5a4d73c010..00000000000
--- a/3rdparty/asio/src/doc/overview/ssl.qbk
+++ /dev/null
@@ -1,123 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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:ssl SSL]
-
-Asio contains classes and class templates for basic SSL support. These classes
-allow encrypted communication to be layered on top of an existing stream, such
-as a TCP socket.
-
-Before creating an encrypted stream, an application must construct an SSL
-context object. This object is used to set SSL options such as verification
-mode, certificate files, and so on. As an illustration, client-side
-initialisation may look something like:
-
- ssl::context ctx(ssl::context::sslv23);
- ctx.set_verify_mode(ssl::verify_peer);
- ctx.load_verify_file("ca.pem");
-
-To use SSL with a TCP socket, one may write:
-
- ssl::stream<ip::tcp::socket> ssl_sock(my_io_context, ctx);
-
-To perform socket-specific operations, such as establishing an outbound
-connection or accepting an incoming one, the underlying socket must first be
-obtained using the `ssl::stream` template's [link
-asio.reference.ssl__stream.lowest_layer `lowest_layer()`] member function:
-
- ip::tcp::socket::lowest_layer_type& sock = ssl_sock.lowest_layer();
- sock.connect(my_endpoint);
-
-In some use cases the underlying stream object will need to have a longer
-lifetime than the SSL stream, in which case the template parameter should be a
-reference to the stream type:
-
- ip::tcp::socket sock(my_io_context);
- ssl::stream<ip::tcp::socket&> ssl_sock(sock, ctx);
-
-SSL handshaking must be performed prior to transmitting or receiving data over
-an encrypted connection. This is accomplished using the `ssl::stream`
-template's [link asio.reference.ssl__stream.handshake handshake()] or [link
-asio.reference.ssl__stream.async_handshake async_handshake()] member functions.
-
-Once connected, SSL stream objects are used as synchronous or asynchronous read
-and write streams. This means the objects can be used with any of the [link
-asio.reference.read read()], [link asio.reference.async_read async_read()],
-[link asio.reference.write write()], [link asio.reference.async_write
-async_write()], [link asio.reference.read_until read_until()] or [link
-asio.reference.async_read_until async_read_until()] free functions.
-
-[heading Certificate Verification]
-
-Asio provides various methods for configuring the way SSL certificates are
-verified:
-
-* [link asio.reference.ssl__context.set_default_verify_paths ssl::context::set_default_verify_paths()]
-* [link asio.reference.ssl__context.set_verify_mode ssl::context::set_verify_mode()]
-* [link asio.reference.ssl__context.set_verify_callback ssl::context::set_verify_callback()]
-* [link asio.reference.ssl__context.load_verify_file ssl::context::load_verify_file()]
-* [link asio.reference.ssl__stream.set_verify_mode ssl::stream::set_verify_mode()]
-* [link asio.reference.ssl__stream.set_verify_callback ssl::stream::set_verify_callback()]
-
-To simplify use cases where certificates are verified according to the rules in
-RFC 2818 (certificate verification for HTTPS), Asio provides a reusable
-verification callback as a function object:
-
-* [link asio.reference.ssl__rfc2818_verification ssl::rfc2818_verification]
-
-The following example shows verification of a remote host's certificate
-according to the rules used by HTTPS:
-
- using asio::ip::tcp;
- namespace ssl = asio::ssl;
- typedef ssl::stream<tcp::socket> ssl_socket;
-
- // Create a context that uses the default paths for
- // finding CA certificates.
- ssl::context ctx(ssl::context::sslv23);
- ctx.set_default_verify_paths();
-
- // Open a socket and connect it to the remote host.
- asio::io_context io_context;
- ssl_socket sock(io_context, ctx);
- tcp::resolver resolver(io_context);
- tcp::resolver::query query("host.name", "https");
- asio::connect(sock.lowest_layer(), resolver.resolve(query));
- sock.lowest_layer().set_option(tcp::no_delay(true));
-
- // Perform SSL handshake and verify the remote host's
- // certificate.
- sock.set_verify_mode(ssl::verify_peer);
- sock.set_verify_callback(ssl::rfc2818_verification("host.name"));
- sock.handshake(ssl_socket::client);
-
- // ... read and write as normal ...
-
-[heading SSL and Threads]
-
-SSL stream objects perform no locking of their own. Therefore, it is essential
-that all asynchronous SSL operations are performed in an implicit or explicit
-[link asio.overview.core.strands strand]. Note that this means that no
-synchronisation is required (and so no locking overhead is incurred) in single
-threaded programs.
-
-[heading See Also]
-
-[link asio.reference.ssl__context ssl::context],
-[link asio.reference.ssl__rfc2818_verification ssl::rfc2818_verification],
-[link asio.reference.ssl__stream ssl::stream],
-[link asio.examples.cpp03_examples.ssl SSL example].
-
-[heading Notes]
-
-[@http://www.openssl.org OpenSSL] is required to make use of Asio's SSL
-support. When an application needs to use OpenSSL functionality that is not
-wrapped by Asio, the underlying OpenSSL types may be obtained by calling [link
-asio.reference.ssl__context.native_handle `ssl::context::native_handle()`] or
-[link asio.reference.ssl__stream.native_handle `ssl::stream::native_handle()`].
-
-[endsect]
diff --git a/3rdparty/asio/src/doc/overview/strands.qbk b/3rdparty/asio/src/doc/overview/strands.qbk
deleted file mode 100644
index 0b6ff050dc6..00000000000
--- a/3rdparty/asio/src/doc/overview/strands.qbk
+++ /dev/null
@@ -1,85 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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:strands Strands: Use Threads Without Explicit Locking]
-
-A strand is defined as a strictly sequential invocation of event handlers (i.e.
-no concurrent invocation). Use of strands allows execution of code in a
-multithreaded program without the need for explicit locking (e.g. using
-mutexes).
-
-Strands may be either implicit or explicit, as illustrated by the following
-alternative approaches:
-
-* Calling io_context::run() from only one thread means all event handlers
- execute in an implicit strand, due to the io_context's guarantee that handlers
- are only invoked from inside run().
-
-* Where there is a single chain of asynchronous operations associated with a
- connection (e.g. in a half duplex protocol implementation like HTTP) there is
- no possibility of concurrent execution of the handlers. This is an implicit
- strand.
-
-* An explicit strand is an instance of `strand<>` or `io_context::strand`. All
- event handler function objects need to be bound to the strand using
- `asio::bind_executor()` or otherwise posted/dispatched through the strand
- object.
-
-In the case of composed asynchronous operations, such as `async_read()` or
-`async_read_until()`, if a completion handler goes through a strand, then all
-intermediate handlers should also go through the same strand. This is needed to
-ensure thread safe access for any objects that are shared between the caller
-and the composed operation (in the case of `async_read()` it's the socket,
-which the caller can `close()` to cancel the operation).
-
-This is done by partially specialising the `asio::ssociated_executor<>` trait
-for all intermediate handlers. This trait forwards to the corresponding trait
-specialisation for the final handler:
-
- struct my_handler
- {
- void operator()() { ... }
- };
-
- namespace asio {
-
- template <class Executor>
- struct associated_executor<my_handler, Executor>
- {
- // Custom implementation of Executor type requirements.
- typedef my_executor type;
-
- // Return a custom executor implementation.
- static type get(const my_handler&, const Executor& = Executor())
- {
- return my_executor();
- }
- };
-
- } // namespace asio
-
-The `asio::bind_executor()` function is a helper to bind a specific executor
-object, such as a strand, to a completion handler. This binding automatically
-specialises the `associated_executor` trait as shown above. For example, to
-bind a strand to a completion handler we would simply write:
-
- my_socket.async_read_some(my_buffer,
- asio::bind_executor(my_strand,
- [](error_code ec, size_t length)
- {
- // ...
- }));
-
-[heading See Also]
-
-[link asio.reference.bind_executor bind_executor],
-[link asio.reference.strand strand],
-[link asio.reference.io_context__strand io_context::strand],
-[link asio.tutorial.tuttimer5 tutorial Timer.5],
-[link asio.examples.cpp03_examples.http_server_3 HTTP server 3 example].
-
-[endsect]
diff --git a/3rdparty/asio/src/doc/overview/streams.qbk b/3rdparty/asio/src/doc/overview/streams.qbk
deleted file mode 100644
index ea89e8b5d62..00000000000
--- a/3rdparty/asio/src/doc/overview/streams.qbk
+++ /dev/null
@@ -1,62 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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:streams Streams, Short Reads and Short Writes]
-
-Many I/O objects in Asio are stream-oriented. This means that:
-
-* There are no message boundaries. The data being transferred is a continuous
- sequence of bytes.
-
-* Read or write operations may transfer fewer bytes than requested. This is
- referred to as a short read or short write.
-
-Objects that provide stream-oriented I/O model one or more of the following
-type requirements:
-
-* `SyncReadStream`, where synchronous read operations are performed using a
- member function called `read_some()`.
-
-* `AsyncReadStream`, where asynchronous read operations are performed using a
- member function called `async_read_some()`.
-
-* `SyncWriteStream`, where synchronous write operations are performed using a
- member function called `write_some()`.
-
-* `AsyncWriteStream`, where synchronous write operations are performed using a
- member function called `async_write_some()`.
-
-Examples of stream-oriented I/O objects include `ip::tcp::socket`,
-`ssl::stream<>`, `posix::stream_descriptor`, `windows::stream_handle`, etc.
-
-Programs typically want to transfer an exact number of bytes. When a short read
-or short write occurs the program must restart the operation, and continue to
-do so until the required number of bytes has been transferred. Asio provides
-generic functions that do this automatically: `read()`, `async_read()`,
-`write()` and `async_write()`.
-
-[heading Why EOF is an Error]
-
-* The end of a stream can cause `read`, `async_read`, `read_until` or
- `async_read_until` functions to violate their contract. E.g.
- a read of N bytes may finish early due to EOF.
-
-* An EOF error may be used to distinguish the end of a stream from a successful
- read of size 0.
-
-[heading See Also]
-
-[link asio.reference.async_read async_read()],
-[link asio.reference.async_write async_write()],
-[link asio.reference.read read()],
-[link asio.reference.write write()],
-[link asio.reference.AsyncReadStream AsyncReadStream],
-[link asio.reference.AsyncWriteStream AsyncWriteStream],
-[link asio.reference.SyncReadStream SyncReadStream],
-[link asio.reference.SyncWriteStream SyncWriteStream].
-
-[endsect]
diff --git a/3rdparty/asio/src/doc/overview/sync_op.dot b/3rdparty/asio/src/doc/overview/sync_op.dot
deleted file mode 100644
index f3eb4dd4008..00000000000
--- a/3rdparty/asio/src/doc/overview/sync_op.dot
+++ /dev/null
@@ -1,67 +0,0 @@
-digraph g
-{
- graph
- [
- nodesep="0.6"
- ];
-
- edge
- [
- fontname="Helvetica",
- fontsize=10,
- labelfontname="Helvetica",
- labelfontsize=10
- ];
-
- node
- [
- fontname="Helvetica",
- fontsize=10,
- shape=box
- ];
-
- edge
- [
- arrowhead="open"
- ]
-
- // Program elements.
- {
- operating_system [ label="Operating System", shape=ellipse ];
- io_context [ label="io_context" ];
- io_object [ label="I/O Object\ne.g. socket" ];
- your_program [ label="Your Program" ];
- }
-
- // Owning relationships.
- {
- edge [ arrowtail="diamond" ];
- your_program:w -> io_object:nw;
- your_program:se -> io_context:ne;
- }
-
- // Non-owning relationships;
- {
- io_object:sw -> io_context:w;
- }
-
- // Actions.
- {
- edge [ style="dashed", color="#808080" ];
-
- // Forward actions.
- {
- your_program:sw -> io_object:n [ label="1" ];
- io_object:s -> io_context:nw [ label="2" ];
- io_context:sw -> operating_system:nw [ label="3" ];
- }
-
- // Reverse actions.
- {
- edge [ arrowhead="none", arrowtail="open" ];
- io_context:se -> operating_system:ne [ label="4" ];
- io_object:se -> io_context:n [ label="5" ];
- your_program:s -> io_object:ne [ label="6" ];
- }
- }
-}
diff --git a/3rdparty/asio/src/doc/overview/sync_op.png b/3rdparty/asio/src/doc/overview/sync_op.png
deleted file mode 100644
index a96c8351b9f..00000000000
--- a/3rdparty/asio/src/doc/overview/sync_op.png
+++ /dev/null
Binary files differ
diff --git a/3rdparty/asio/src/doc/overview/threads.qbk b/3rdparty/asio/src/doc/overview/threads.qbk
deleted file mode 100644
index b5239d9828e..00000000000
--- a/3rdparty/asio/src/doc/overview/threads.qbk
+++ /dev/null
@@ -1,66 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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:threads Threads and Asio]
-
-[heading Thread Safety]
-
-In general, it is safe to make concurrent use of distinct objects, but unsafe
-to make concurrent use of a single object. However, types such as `io_context`
-provide a stronger guarantee that it is safe to use a single object
-concurrently.
-
-[heading Thread Pools]
-
-Multiple threads may call `io_context::run()` to set up a pool of threads from
-which completion handlers may be invoked. This approach may also be used with
-`io_context::post()` to use a means to perform any computational tasks across a
-thread pool.
-
-Note that all threads that have joined an `io_context`'s pool are considered
-equivalent, and the `io_context` may distribute work across them in an
-arbitrary fashion.
-
-[heading Internal Threads]
-
-The implementation of this library for a particular platform may make use of
-one or more internal threads to emulate asynchronicity. As far as possible,
-these threads must be invisible to the library user. In particular, the threads:
-
-* must not call the user's code directly; and
-
-* must block all signals.
-
-This approach is complemented by the following guarantee:
-
-* Asynchronous completion handlers will only be called from threads that are
- currently calling `io_context::run()`.
-
-Consequently, it is the library user's responsibility to create and manage all
-threads to which the notifications will be delivered.
-
-The reasons for this approach include:
-
-* By only calling `io_context::run()` from a single thread, the user's code can
- avoid the development complexity associated with synchronisation. For
- example, a library user can implement scalable servers that are
- single-threaded (from the user's point of view).
-
-* A library user may need to perform initialisation in a thread shortly after
- the thread starts and before any other application code is executed. For
- example, users of Microsoft's COM must call `CoInitializeEx` before any other
- COM operations can be called from that thread.
-
-* The library interface is decoupled from interfaces for thread creation and
- management, and permits implementations on platforms where threads are not
- available.
-
-[heading See Also]
-
-[link asio.reference.io_context io_context].
-
-[endsect]
diff --git a/3rdparty/asio/src/doc/overview/timers.qbk b/3rdparty/asio/src/doc/overview/timers.qbk
deleted file mode 100644
index 0c5528dcc1b..00000000000
--- a/3rdparty/asio/src/doc/overview/timers.qbk
+++ /dev/null
@@ -1,52 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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:timers Timers]
-
-Long running I/O operations will often have a deadline by which they must have
-completed. These deadlines may be expressed as absolute times, but are often
-calculated relative to the current time.
-
-As a simple example, to perform a synchronous wait operation on a timer using a
-relative time one may write:
-
- io_context i;
- ...
- deadline_timer t(i);
- t.expires_from_now(boost::posix_time::seconds(5));
- t.wait();
-
-More commonly, a program will perform an asynchronous wait operation on a
-timer:
-
- void handler(asio::error_code ec) { ... }
- ...
- io_context i;
- ...
- deadline_timer t(i);
- t.expires_from_now(boost::posix_time::milliseconds(400));
- t.async_wait(handler);
- ...
- i.run();
-
-The deadline associated with a timer may also be obtained as a relative time:
-
- boost::posix_time::time_duration time_until_expiry
- = t.expires_from_now();
-
-or as an absolute time to allow composition of timers:
-
- deadline_timer t2(i);
- t2.expires_at(t.expires_at() + boost::posix_time::seconds(30));
-
-[heading See Also]
-
-[link asio.reference.basic_deadline_timer basic_deadline_timer],
-[link asio.reference.deadline_timer deadline_timer],
-[link asio.tutorial.tuttimer1 timer tutorials].
-
-[endsect]
diff --git a/3rdparty/asio/src/doc/overview/windows.qbk b/3rdparty/asio/src/doc/overview/windows.qbk
deleted file mode 100644
index da49a0b409e..00000000000
--- a/3rdparty/asio/src/doc/overview/windows.qbk
+++ /dev/null
@@ -1,126 +0,0 @@
-[/
- / Copyright (c) 2003-2016 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:windows Windows-Specific Functionality]
-
-[link asio.overview.windows.stream_handle Stream-Oriented HANDLEs]
-
-[link asio.overview.windows.random_access_handle Random-Access HANDLEs]
-
-[link asio.overview.windows.object_handle Object HANDLEs]
-
-[section:stream_handle Stream-Oriented HANDLEs]
-
-Asio contains classes to allow asynchronous read and write operations to be
-performed on Windows `HANDLE`s, such as named pipes.
-
-For example, to perform asynchronous operations on a named pipe, the following
-object may be created:
-
- HANDLE handle = ::CreateFile(...);
- windows::stream_handle pipe(my_io_context, handle);
-
-These are then used as synchronous or asynchronous read and write streams. This
-means the objects can be used with any of the [link asio.reference.read
-read()], [link asio.reference.async_read async_read()], [link
-asio.reference.write write()], [link asio.reference.async_write
-async_write()], [link asio.reference.read_until read_until()] or [link
-asio.reference.async_read_until async_read_until()] free functions.
-
-The kernel object referred to by the `HANDLE` must support use with I/O
-completion ports (which means that named pipes are supported, but anonymous
-pipes and console streams are not).
-
-[heading See Also]
-
-[link asio.reference.windows__stream_handle windows::stream_handle].
-
-[heading Notes]
-
-Windows stream `HANDLE`s are only available at compile time when targeting
-Windows and only when the I/O completion port backend is used (which is the
-default). A program may test for the macro `ASIO_HAS_WINDOWS_STREAM_HANDLE` to
-determine whether they are supported.
-
-[endsect]
-
-[/-----------------------------------------------------------------------------]
-
-[section:random_access_handle Random-Access HANDLEs]
-
-Asio provides Windows-specific classes that permit asynchronous read and write
-operations to be performed on HANDLEs that refer to regular files.
-
-For example, to perform asynchronous operations on a file the following object
-may be created:
-
- HANDLE handle = ::CreateFile(...);
- windows::random_access_handle file(my_io_context, handle);
-
-Data may be read from or written to the handle using one of the
-`read_some_at()`, `async_read_some_at()`, `write_some_at()` or
-`async_write_some_at()` member functions. However, like the equivalent
-functions (`read_some()`, etc.) on streams, these functions are only required
-to transfer one or more bytes in a single operation. Therefore free functions
-called [link asio.reference.read_at read_at()], [link
-asio.reference.async_read_at async_read_at()], [link asio.reference.write_at
-write_at()] and [link asio.reference.async_write_at async_write_at()] have been
-created to repeatedly call the corresponding [^[**]_some_at()] function until
-all data has been transferred.
-
-[heading See Also]
-
-[link asio.reference.windows__random_access_handle windows::random_access_handle].
-
-[heading Notes]
-
-Windows random-access `HANDLE`s are only available at compile time when
-targeting Windows and only when the I/O completion port backend is used (which
-is the default). A program may test for the macro
-`ASIO_HAS_WINDOWS_RANDOM_ACCESS_HANDLE` to determine whether they are
-supported.
-
-[endsect]
-
-[/-----------------------------------------------------------------------------]
-
-[section:object_handle Object HANDLEs]
-
-Asio provides Windows-specific classes that permit asynchronous wait operations
-to be performed on HANDLEs to kernel objects of the following types:
-
-* Change notification
-* Console input
-* Event
-* Memory resource notification
-* Process
-* Semaphore
-* Thread
-* Waitable timer
-
-For example, to perform asynchronous operations on an event, the following
-object may be created:
-
- HANDLE handle = ::CreateEvent(...);
- windows::object_handle file(my_io_context, handle);
-
-The `wait()` and `async_wait()` member functions may then be used to wait until
-the kernel object is signalled.
-
-[heading See Also]
-
-[link asio.reference.windows__object_handle windows::object_handle].
-
-[heading Notes]
-
-Windows object `HANDLE`s are only available at compile time when targeting
-Windows. Programs may test for the macro `ASIO_HAS_WINDOWS_OBJECT_HANDLE` to
-determine whether they are supported.
-
-[endsect]
-
-[endsect]