Subject: Re: [boost] [beast] Wy does message<> store Body::value_type?
From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2017-07-02 15:03:05
This is a compelling *rationale*. (See what I did there?)
On Jul 2, 2017 5:08 AM, "Vinnie Falco via Boost" <boost_at_[hidden]>
> 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
> > 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
> 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.
> Unsubscribe & other changes: http://lists.boost.org/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk