Boost logo

Boost :

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?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk