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

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2023-02-04 14:55:55

pt., 3 lut 2023 o 02:13 Vinnie Falco via Boost <boost_at_[hidden]>
napisał(a):

> 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.
>

On the specific topic of OptionalLike, note that we have i Boost the
concept of OptionalPointee:
https://github.com/boostorg/utility/blob/c960bef6ef005413d96cc7366b66cbdf56d47110/include/boost/utility/compare_pointees.hpp
It is not well advertised though. It was added along Boost.Optional, but it
was not clear where to put it.

> 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.
>

Agreed. A library for enforcing concepts from Boost.Libraries.

Regards,
&rzej;

>
> 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
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>