This is a compelling *rationale*. (See what I did there?) Zach On Jul 2, 2017 5:08 AM, "Vinnie Falco via Boost" wrote:

On Sun, Jul 2, 2017 at 1:40 AM, Peter Dimov via Boost wrote:

...

Why does message 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. responsestd::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

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost