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