Re: [boost] [review][beast] Review of Beast starts today : July 1 - July 10

On Sat, Jul 1, 2017 at 6:20 PM, Zach Laine via Boost wrote:

They don't seem that different to me. The data look the same from the outside, but the underlying structure is different. The underlying structure doesn't seem like it *needs* to be different, though. One could be flattened into the other. These are all views, right? Cheap-to-copy views? So, in terms of the existing types, if buffer_cat() returned a buffer_prefix_view with n=0, would that break things? I mean a semantic breakage, not a compilation breakage.

Perhaps it is possible to combine the functionality of buffer_prefix_view and buffer_cat_view, but it would come at the expense of a larger object. Buffer sequences are supposed to be copyable and normally they are not particularly large. For example beast::multi_buffer::const_buffers_type costs just one pointer and therefore pretty darn cheap. But some parts of Beast declare truly gnarly buffer sequences, like this one: https://github.com/vinniefalco/Beast/blob/78a065ba39836d91d7e70d93de7f9140f5... using ch2_t = consuming_buffers>; reader::const_buffers_type can itself be a buffer_cat_view or some other sort of adapted buffer sequence, it depends on the traits of the Body being used. Chris was very helpful in working with me to optimize the http-server-fast example, he pointed out that the size of this buffer was exactly 256 bytes which unfortunately is one byte larger than it needs to be in order to take advantage of an Boost.Asio implementation optimization. I got lucky and found an unused member in consuming_buffers which I was able to remove. The moral of the story is that sizeof(ConstBufferSequence) counts, so these buffer range adapters need to be separate in order to be as small as possible. Thanks