Boost logo

Boost :

Subject: Re: [boost] [beast] Wy does message<> store Body::value_type?
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2017-07-02 10:08:10


On Sun, Jul 2, 2017 at 1:40 AM, Peter Dimov via Boost
<boost_at_[hidden]> wrote:
> Why does message<isRequest, Body, Fields> store Body::value_type, using
> Body::reader and Body::writer to manipulate it, instead of the more
> straightforward approach of storing Body, which would have allowed making
> `get` and `put` members of the Body directly, instead of using intermediate
> classes?

`reader::get` and `writer::put` are part of the interfaces used to
serialize and parse the body respectively. There can be state
information associated with those operations which doesn't belong in
the body and exists only during the parse or serialization. For
example file_body stores FILE* during I/O. Using `Body body` instead
of `Body::value_type body` would force every implementation of Body to
store state information in the message. const messages could never be
serialized or accessed from two threads simultaneously.

Another problem with requiring Body::get and Body::put is that it is
intrusive. Existing containers could not be used as Body types due to
the additional requirements. response<std::string> wouldn't work. This
imposes an unnecessary burden on anyone who wants to use a particular
container: a new class must be written which wraps the container and
its interfaces, then adds the necessary get() and put() members.
`string_body body` would have to duplicate every member function of
std::string.

The current implementation is flexible and expressive. Any container
may be used as the type for the message::body member. Users can add
the required reader and writer implementations non-intrusively. State
required only during serialization or parsing is managed outside of
the container. Messages may be serialized by multiple threads
concurrently. The scheme Beast uses for selecting the message body
type is one of the defining characteristics of the library, and to my
knowledge is the first of its kind.

Thanks


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk