Sorry, I don't think that's an accurate statement of anything. This is accurate:
In a given translation unit (TU), all combinations of A and T, where A is an archive registered (in the TU) with BOOST_SERIALIZATION_REGISTER_ARCHIVE and T is a class exported (in the TU) with BOOST_CLASS_EXPORT(**) are used to instantiate polymorphic pointer serialization code. Period.
The translation unit or some portion of it may later be discarded if the linker can prove none of its functions or objects are used, or else its initializers may be skipped. Separate issue.
Just to clarify, besides the portability issues, I brought up the issue of the templates being instantiated by the BOOST_CLASS_EXPORT macro because it introduces physical coupling between the classes being registered and the serialization library. Perhaps I need to clarify what I mean. //foo.h class foo; template <class A> void operator<<( A &, foo const & ); class foo { public: foo(); private: int m_; template <class A> friend void operator<<( A &, foo const & ); }; template <class A> void operator<<( A & a, foo const & x ) { a << x.m_; } The above foo.h defines class foo, and also specifies how objects of class foo are serialized, yet there is no (physical) coupling between foo.h and a serialization library, because foo.h does not include any headers. This is a good thing: typically, most of the compilation units that #include "foo.h" will not serialize foo objects; the ones that do serialize foo objects will know to #include "foo.h" and a (compatible) serialization library. Also consider that I can write a program that makes use of class foo yet doesn't use/include/link a serialization library. This would not be possible if foo.cpp auto-registers class foo with a serialization library.