Well, this went a little off-topic, but I still would like to know why Robert thinks that adding aliases is a bad idea. It seems to me that my mistake is a pretty likely one in the long term, and so the Serialization library needs to provide a way to recover from such mistakes, or reduce the chances of their introduction altogether (by removing BOOST_CLASS_EXPORT()). At the very least, if BOOST_CLASS_EXPORT() is to stay, an explicit note regarding this pitfall should be added to the docs. Again, I am happy to write a patch for the code and/or docs. Zach Laine On 3/16/07, Emil Dotchevski <emildotchevski@hotmail.com> wrote:
So to me it seems natural to included in the header along with the whole class declaration.
Consider a library that provides foo.h, which defines class foo, and a program that #includes "foo.h" because it needs to use class foo, but it doesn't need to serialize it. To me, it isn't natural for such a program to require boost serialization headers.
I suppose you could separate serialize/load/save overloads in a different header file, but because typically they need to be friends, foo.h would have to declare them in order to make them friends, which is a hassle. Instead, you could simply define serialize/load/save directly in foo.h without including any serialization stuff -- except that a program that does serialize foo objects would have to register class foo "manually".
That way when that header gets used by other programs, they all share the same external name - as they should since they're sharing the same header.
If I want to make a particular class to have the same external name across multiple programs, this is easy to achieve by sharing the code that registers that class with boost serialization. I just don't think that the class' header file is the best place for this registration.
Emil Dotchevski
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost