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. So 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 serialization code. 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 be required. So 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. Robert Ramey 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>?
Thanks,
Eric