Re: [boost] [Serliazation] Auto registration/physical coupling(was:Thread-safety again)

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2007-01-04 18:17:27

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?