I'm upgrading a large data analysis project from boost 1.38 to 1.52 (see this 2008 Boostcon talk for details: http://www.icecube.umd.edu/~troy/talks/icefishing.pdf). Everything has gone remarkably smoothly, with a minimal degree of #if, except for one thing: a change in the semantics of BOOST_CLASS_EXPORT. The software is organized into a number of shared libraries each of which have serializable classes that generally inherit from a shared base class, through pointers to which the derived classes are almost always [de]serialized to/from a custom archive type. When using 1.38, the BOOST_CLASS_EXPORT directive was kept in the implementation file for each serializable class. This almost still works for 1.52 but can result in strange behavior that took me two days to track down. Some of our classes would report through unregistered class errors on [de]serialization. Which ones would depend on circumstances, compiler version, linker, and operating system. The reason turns out to be changes in handling of the class GUID. This is associated to the pointer serializer by BOOST_CLASS_EXPORT -- but also now apparently by the first instantiated code [de]serializing the class through that archive directly based on the presence of a template specialization of boost::serialization::guid<T>() currently in scope, which is NULL by default. Once NULL is set as the GUID, it stays that way, regardless of a proper BOOST_CLASS_EXPORT later. This occurred in our case as a result of def_pickle() calls in boost.python bindings that used the same classes and archive type. This can be fixed by BOOST_CLASS_EXPORT_KEY in all appropriate header files. Adding it is a sizeable amount of work (hundreds of classes) but I'm more concerned the mechanism is very fragile in the case of templates and I'm not sure what to do there. For example, we have a generic serializable container. Any specialization of it needs to be registered with BOOST_CLASS_EXPORT, which is fine, but anyone using that specialization needs to also include a header file BOOST_CLASS_EXPORT_KEY() in it for that particular specialization as well. In other words, you can't just use container<Foo> and expect it to work reliably and, moreover, if you use it *once* without having seen the right in-scope macro, it will break serialization of that type globally if you happen to have linked against a library that made this mistake. Probably. Depending on initialization order. So my questions: 1. Is it possible for things that would return GUIDs of NULL to try harder and look in a global registry instead of silently breaking things? This kind of global lookup was how 1.38 always worked and it seems considerably less fragile. 2. Is there a way to handle BOOST_CLASS_EXPORT_KEY() sanely in the case of templates without the risk of silent serialization failures -- in all instances of that class -- that depend on global initialization order? 3. Is it possible to change the GUID set in the extended type info object of a pointer_[i/o]serializer at runtime after the class has been added to the export registry? 4. Are there any suggested mechanisms for local hacks, given that we control the archive implementation, to implement 1-3 without changes to boost? -Nathan