Subject: [boost] Boost.Buffers, a new library from the makers of Beast!
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2017-10-03 20:43:00
During the formal review of Beast, desires were expressed to use
components like the HTTP parser and serializer independently from the
rest of the library. The sticking point was the abstraction used to
represent a range of non-owning buffers. In particular, Asio imposes
certain concrete type requirements in its ConstBufferSequence and
It would seem there is significant interest in making some components
of Beast modular, in their own libraries. The main feature of these
components would be that they should not require Boost.Asio.
Unfortunately, the way Asio's concepts are defined this is not
Two solutions present themselves:
1. Create a new buffer sequence concept which retains all the features
of Asio's concepts but does not require the concrete types. While this
is possible it would create a significant complication. Interfaces
which use the new concept would require some kind of adapter at every
call site that tries to use a traditional Asio style interface.
2. Create a new library which uses conditional compilation to either
include just the Asio header files which fulfill the needs for
interacting with buffer sequence concepts, or provide the declarations
directly from a copy of the Asio sources.
The solution used in Boost.Buffers (a new library I am considering
proposing) is choice number two.
Someone who wants to create a new library ("Foo") that does no network
I/O but wants to interoperate with Asio buffer concepts merely need to
do the following
and then, in their build script for the tests and examples, set:
#define BOOST_NET_BUFFER_NO_ASIO 1
This works because Boost.Buffers contains copies of all the necessary
header files to work with buffer sequences, and JUST those header
files. All of Boost.Asio is not necessary:
Now if someone wants to use library Foo they will also be getting a
dependency on Boost.Buffers. If that user doesn't need Asio, then they
will also set the macro to 1 in their build script. However. if that
user wants to use Asio in their program or library, they just set
#define BOOST_NET_BUFFER_NO_ASIO 0
and now Boost.Buffers will simply include the relevant Asio header files.
This library will allow the creation of new libraries which use Asio
buffer concepts, but do not require all of Boost.Asio as a dependency,
as well as all the things that Boost.Asio is dependent on, which is
non-trivial as can be seen here:
I would like feedback on this library before I move forward with it,
as you can imagine it has some controversial aspects to it.
Boost.Buffers is here:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk