Is there a particular reason why the serialization library does not provide serialization functions for types in other boost libraries? Unless I've missed them, but I find I've had to provide implementations for, e.g.: boost::filesystem::path - trivial. boost::multi_array - also seems straightforward, unless I'm missing something there. They don't require invasive techniques, so is it that it's being left up to the particular library owners to decide whether or not to support serialization? If it's an efficiency argument, e.g. one size doesn't fit all, I don't see why 'an' implementation could not be provided (perhaps in /serialization/boost/xyz.hpp). After all, no one would be forced to include/use that particular implementation.
Is there a particular reason why the serialization library does not provide serialization functions for types in other boost libraries?
IIUC, it goes in the opposite direction: other boost libraries do not provide serialization functions for their types. But some libraries do - like MultiIndex, DateTime etc...
"Matthias Troyer" <troyer@phys.ethz.ch> wrote in message news:CBA69A3C-689F-4C61-8C54-DD24AEA0A331@phys.ethz.ch...
Indeed, the serialization codes for classes defined by a library belongs with that library.
However, the serialization library provides serialization for std types. If and when boost::filesystem makes it into the standard, does the library then provide an implementation?
participants (3)
-
Chard -
Igor R -
Matthias Troyer