[boost] [serialization] automatic linking and intrusive serialization support

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2005-02-08 16:12:01

Suppose I'm the user of a class called foo which supports
serialization through intrusive methods. So, foo.h will look
like:

// foo.h

#include <boost/serialization/access.hpp>

// other, non serialization-related includes

class foo
{
  ...
};

Now, a programmer uses foo, but does not take advantage of
its serialization capabilities.

// user.cpp
#include <foo.h>

// use foo

and a second programmer uses foo *and* serializes it.

//user2.cpp
#include <foo.h>
#include <boost/archive/text_oarchive.hpp>

// use foo and its serialization capabilities.

So far so good. Boost 1.33 release of Boost.Serialization,
if I'm not wrong, will include automatic linking, and here comes
the problem: when doing the upgrade to 1.33, user2 will be
delighted that he'll no longer need to do the linking stuff by
himself; but user1 will get mysterious "not found" linking errors,
or worse yet, he'll have Boost.Serialization automagically
bundled into his final executable, when he never explictly
dealed with this lib in the program!

Of course, user1 can set BOOST_SERIALIZATION_NO_LIB and
be done, but this is a burden which I'd like to save
users from, if possible.

So, here comes the question. Suppose the implementer of
foo changes foo.h as follows (please bear with any
preprocessor mistake by my part if there's any, I hope
you get the point nonetheless):

// foo.h

#if defined(BOOST_SERIALIZATION_DYN_LINK)
#  define BACKUP1
#endif
#if defined(BOOST_SERIALIZATION_NO_LIB)
#  define BACKUP2
#endif

#undef BOOST_SERIALIZATION_DYN_LINK
#define BOOST_SERIALIZATION_NO_LIB

#include <boost/serialization/access.hpp>

#if defined(BACKUP1)
#  define BOOST_SERIALIZATION_DYN_LINK
#endif
#if defined(BACKUP2)
#  define BOOST_SERIALIZATION_NO_LIB
#endif

// other, non serialization-related includes

class foo
{
  ...
};

Now, if my idea is correct, user1 won't get
Boost.Serialization autolinked (since
<boost/serialization/access.hpp> was included with
BOOST_SERIALIZATION_NO_LIB), and user2 will benefit
from autolinking, as he included another
Boost.Serialization header on his own. The best of
both worlds.

Do you think this approach would work? Any foreseeable
problem?

Thanks,

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo