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

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.