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

From: Robert Ramey (ramey_at_[hidden])
Date: 2023-02-03 18:14:42

On 2/2/23 2:46 PM, Gavin Lambert via Boost wrote:
> 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.

or ... boost/optional/serialization.hpp ?

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

I have chose the following rule.

a) if it's in the standard, it's in boost/optional
b) if it's somewhere else it's in boost/somewhere_else/optional.hpp

Adding pieces of every other library into boost serialization doesn't 
scale and is not maintainable - at least no by me.

If a user includes boost/optional/serialization.hpp "too high" in the 
inclusion tree it creates spurious dependencies - not a great thing.  If 
one includes a test for serialization inside a library, it makes the 
whole library dependent on the serialization library which in turn ends 
up depending on large parts of boost.  Not what a lot of people want. In 
twenty years we've never been able to resolve this.  I believe there are 
few other "utility types" which have this same problem.

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

> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>