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

From: Gavin Lambert (boost_at_[hidden])
Date: 2023-02-02 22:46:37

On 3/02/2023 10:57, Andrzej Krzemienski wrote:
> We have (I think a still unresolved issue) of Boost-serializing
> Boost.Optional. Should the code responsible for the serialization of
> Boost.Optional be part of Boost.Serialization or Boost.Optional? But we
> will certainly not solve it by introducing yet another library. There are
> other ways to solve it, say, through optional headers.

I think the two schools of thought on that are:

1. Serialization came first and so Optional should take it into account 
in its implementation.
2. Optional is more fundamental than Serialization, and you're more 
likely to use optionals than serialization, so the latter should have 
the supporting code.

I personally find the second argument more compelling (although the 
waters are muddied by there now being a std::optional too, increasing 
the chance you might want serialization without caring about 
boost::optional), but that only solves the problem of which repository 
the bulk of code should belong to.

Unfortunately in C++ there's no way to say "if these two otherwise 
unrelated headers were included then also include this", short of 
order-sensitive preprocessor checks.  This then I think leads to only 
three reasonable solutions:

1. The user has to know that the integration exists and explicitly 
#include an additional header file (e.g. 
boost/serialization/optional.hpp) when they're using both together.

2. *Both* libraries need to detect the other and include the integration 
header from their top-level wrapper regardless of the original include 
order.  So if the user happens to include both libraries "in general" 
then they get the integration automatically.

3. One library decides that the other is sufficiently "vocabulary" 
and/or small enough to always be loaded if the first is, and just 
unconditionally includes it (from the perspective of the "whole library" 
header, at least).

For this particular case, Boost appears to have chosen #1 currently, and 
doesn't implement #2 or #3.  These are not mutually exclusive.

#2 is the most user-friendly option (#1 is less discoverable), but it's 
not readily extensible for detecting if std types are included, or for 
third-party library types unaware of Boost, making it rather awkward in 
practice for anything non-Boost.

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.