Re: Boost.Buffers: network-agnostic buffer types and algorithms

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2023-02-03 01:12:52

On Thu, Feb 2, 2023 at 2:47 PM Gavin Lambert via Boost
<boost_at_[hidden]> wrote:
> I'm not entirely sure how this all applies to the Buffers/Asio
> situation.  Logically, Buffers would be more fundamental than Asio, so
> it would make sense for Asio to be modified to use/be compatible with
> Buffers (rather than the reverse, as currently seems to be proposed),
> though I'm not sure how well that would catch on since Asio will likely
> want to retain its own buffer implementations for standalone use at least.

Well as I mentioned in my previous message, I think that serialization
is a different thing from where Buffers would be applicable. As an
interesting note. Boost.JSON handles conversion of OptionalLike types
to JSON when performing json::value_from and when serializing (soon).
We did this not by depending on Boost.Optional but rather, defining a
concept for all OptionalLike types. Generally speaking I think if a
library wants to support types that match certain generic concepts,
then the place for that support goes into the library itself.

I would be in favor of a Boost library which offered metafunctions for
identifying types which match certain models such as OptionalLike,
MapLike, StringLike (e.g convertibility to string_view), TupleLike,
VariantLike and such. JSON could use that and perhaps Serialization.
It might be worth exploring.

I have designed Boost.Buffers to work with Asio (but without requiring
Asio) to make it palatable to use. Asio changing is extremely unlikely
so the burden is on Buffers to be interoperable.

On a separate note all of this talk about headers only working when
other headers are "present" or anything like that, makes me
uncomfortable. I like it when a build always produces one version of
the library no matter what else is installed or what macros are set.
I've tried to get fancy with includes and I always regretted it.

Thanks