Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk