Le 2010-08-08 à 11:31, Andrei Alexandrescu a écrit : > Good point. This is not a template-specific problem; if you try to > deserialize a derived class and the client doesn't know of that class... well > there's not a lot one can do, unless you package the code of the methods with > the object. > > I think it's reasonable to limit (at least for now) things to requiring that > the client knows about the exact type serialized. And they need to have a > layout-compatible version. Which brings us to a related problem - > versioning...
My preferred way to handle versioning is to not have to handle it. I generally use key-value pairs to store the content of aggregates (structs, classes). This means I can grow the number of members over time while keeping backward compatibility. If a member is missing from the serialization I use the default value or the class/struct can handle the case with a more specialized behaviour. I can also continue serializing a no-logner necessary value to keep the aggregate backward compatible with older code. This also makes things less fragile in regard to layout changes: you don't need to keep variables in the same order on all platforms, in all versions, etc. So that's how I've build my serialization module. I probably should stop talking about it and finish it instead... :-) -- Michel Fortin [email protected] http://michelf.com/ _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
