Boost logo

Boost :

From: Gavin Lambert (boost_at_[hidden])
Date: 2023-02-06 22:43:36


On 4/02/2023 07:14, Robert Ramey wrote:
>> 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 ?

Perhaps, though as I said I find the "optional is more fundamental"
argument more compelling, so by that logic the compatibility code should
be in serialization and not optional.

Also, boost/serialization/optional.hpp already does exist, and
boost/optional/serialization.hpp does not.

Though having both header files exist (with one merely a redirect to the
canonical one) could be an interesting choice, to allow the user to not
have to think about which one is more fundamental. (Though if one file
exists and one does not, that becomes obvious fairly quickly.)

One downside of the current serialization implementation is that (as far
as I can see) it *only* supports boost::optional and not std::optional,
and the "obvious" header name (boost/serialization/optional.hpp) is
already taken. Were it to extend support for std::optional in the
future, how should that look? Just detect C++17 and then assume you
want it automatically? Try to auto-detect a previous #include
<optional>? Assume including boost/serialization/optional.hpp means you
want both? Introduce boost/serialization/std_optional.hpp? All of
these choices have pros and cons.

Another variant might be mixing several of these, by renaming current
optional.hpp to boost_optional.hpp, adding std_optional.hpp, and then a
new optional.hpp that includes one, the other, or both based on C++17
support (or detecting prior include of Boost.Optional), though there are
several caveats there too.


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