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

pt., 3 lut 2023 o 02:13 Vinnie Falco via Boost napisał(a):

On Thu, Feb 2, 2023 at 2:47 PM Gavin Lambert via Boost 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/c960bef6ef005413d96cc7366b66cbdf56d... 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