From: Robert Ramey (ramey_at_[hidden])
Date: 2005-02-06 11:47:21
Serialization for all STL collections is done without changing STL. So, if
one is not using serialization it doesn't have to be included.
I was able to implement serialization for boost::smart_ptr without changing
it. However, my implemention is dependent on the smart pointer
implementation and required access to a couple of private variables from the
smart pointer implementation. The smart pointer didn't expose enough
functionality to do it any other way without makeing changes to the
serialization library itself. This raised hackle in some quarters. The
concern was since smart_ptr is to conform to a standard, it should be
serializable while relying only on its public standard interface. However,
doing this means hanging on an kludge-like appendage on the serialization
library to handle this one case. So far no concensus has been reached on
how to address this.
a) we can agree that serialization should be on optional add on to any
library type and should not require anyone to include serialziation headers
if he is not using this facility. This is the case with all current
b) We prefer that the public interface of a library type be sufficient to
implment serialization. This gives the library author the flexibility to
alter the implementation without invalidating pre-existing archives.
The variant code in question complies with a) above but not b). As far as I
know, variant isn't scheduled for inclusion in that standard so this not be
a huge issue. On the other hand, I believe that the current variant
exposes enough functionality to permit serialization without changes and
without exposing any of its implementation. (I might be wrong here). If
not, I believe only the smallest of additions to its public interface would
a) we have a working version of variant serialization. I believe it
includes a test.
b) It might not be what everyone is happy with.
I would much like to see progress here as I see serialization of a variant
and extremely useful idea which would increase the application of variant.
Applications such as transaction logging come to mind.
This would be the normal case.
Eric Friedman wrote:
> Hi Troy (and others interested in this issue),
> When I have some available time, I will take a look at the code for
> serialization. Sorry for not replying sooner, but I don't check up on
> the Boost list as often as I should.
> One question, as I'm not familiar with the serialization library.
> What effect do the proposed changes have on those users of variant
> who do not need/want serialization support? Obviously there is the
> addition #include, but does this imply overhead, or is the header
> simply forward declares in the spirit of <iosfwd>?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk