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

From: Robert Ramey (ramey_at_[hidden])
Date: 2023-02-07 14:51:44

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

I think we're off-topic - but what the hell.

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

My rule has always been:

if it's in the standard library, put it in boost/serialization/...

otherwise, put it in boost/<library name>/serialization.hpp

I didn't see any natural place for the standard library serializations 
so I put them boost/serialization.  A big problem is that a number of 
library maintainers object to putting the serialization code for their 
data types into their libraries and won't do it.  This explains the 
"optional" anomaly you've noted.  They don't like it because our 
"dependency checking tools"  Will show a dependency on serialization if 
the serialization library is referred to anywhere in a library, even if 
only in tests!  Basically "dependency" would depend on whether an 
application actually serializes that type.  Of course if one is building 
a shared library it's different - everything has to be included.  Sorry 
for the wordy explanation, but I didn't have time to make it shorter.
> 
> Also, boost/serialization/optional.hpp already does exist, and 
> boost/optional/serialization.hpp does not.

Because the maintainer of optional has chosen not to.  If I put it in 
serialization, I'm signing on to adding/maintaining serialization types 
in all libraries.  Probably not a wise idea.  I don't want the work and 
I'm 75 years old.
> 
> 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.)

So it's not a question of which is more "fundamental", which would 
always be subjective, it's just the simple rule above.
> 
> 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.

I think there is an implementation of serialization posted as a PR.

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

This really is a question regarding "bridge libraries" which have a foot 
in more than library.  The "real" solution would be a separate "library" 
which would contain just the serialization implementations for all types.

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