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