I think I do not understand.
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.
We have considered that. And there is even a specific test to be sure that serialization code isn't included if serialization isn't being used. The test is test_include. You can use BOOST_CLASS_EXPORT in a header and extra code will be generated until you do: ar << t
a) So, what I suggest is using BOOST_CLASS_EXPORT in one's header;
How am I supposed to use BOOST_CLASS_EXPORT without including a header file from the serialization library? Including serialization library headers introduces physical coupling between foo.h and the serialization library, because as Dave pointed out, BOOST_CLASS_EXPORT instantiates all kinds of templates. You would be relying on the optimizer to strip those instances if they're not used, but the physical coupling is still there.
b) Declare - but don't define the serialize function c) in a separate foo.ipp define serialize function. d) make one module which includes foo.ipp and compile it and add it to your library of common application types. This module will include headers for all archives you expect to use or alternatively, the polymorphic archive.
Wouldn't that mean that foo.ipp (which I suppose is part the "foo" stuff and is therefore shared between all projects that use foo) would have to know in advance what archives I will be using to serialize foo objects? Note that in my example above, I don't merely declare the serialization function, I define it but I do not include any headers. Now each project that uses foo can include different (including unknown in advance) archives and still use the serialization functionality defined by foo.h. Alternatively, a project that uses foo is free to not include any archives and to not call serialization functions. I don't see how this could be achieved in the system you describe. I would not be able to build a project that uses foo if boost serialization is unavailable, whereas in my example that's possible.
e) include foo.hpp in any program which calls any functions on foo - including serialization. f) compile application. g) link with library of common application types.
If the application uses serialization, it gets the code from the library. Otherwise not.
Yet there is still physical coupling between foo.h and the serialization library. Or am I missing something?