[boost] Re: Re: [serialization] automatic linkingandintrusiveserialization support

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-02-08 20:07:08

JOAQUIN LOPEZ MU?Z wrote:
> ----- Mensaje original -----
> De: Robert Ramey <ramey_at_[hidden]>
> Fecha: Miércoles, Febrero 9, 2005 0:20 am
> Asunto: [boost] Re: [serialization] automatic linking
> andintrusiveserialization support
> [...]
>> fJOAQUIN LOPEZ MU?Z wrote:
> [...]
>>> 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!
>>
>> I don't believe this is the case. Templated code is not emitted
>> unless explictly invoked.  If user2 never serializes anything the
>> then
>> the member
>> serialization template won't be expanded.  This view is supported
>> by the
>> fact that if serialization isn't used - then no *_iarchive.hpp
>> file is
>> included so the template argument Archive has no known value so its
>> impossible for the compiler emit the code.
>>
>
> I think I'm not explaining myself clearly. I agree
> with you that user1 won't cause any serialization-related
> code to be emited by the *compiler*. The problem is that,
> by virtue of the internal #include <boost/serialization/access.hpp>
> in foo.h, he will get Boost.Serialization autolinked,
> because <boost/serialization/access.hpp> (or some other
> serialization header, don't know precisely) ultimately
> includes auto_link.hpp.
> In other words: he will stumble upon Boost.Serialization
> binary without ever explicity mentioning or trying to
> use this library.
>
> At the risk of repeating myself, try compiling the
> following:
>
> #include <boost/serialization/access.hpp>
>
> int main(){}
>
> If I'm correct, autolinking will kick in yet the program
> does not use Boost.Serialization at all. Of course
> the program has included a serialization header so it
> should face the consequences, but in the problem I describe
> that header is included internally and the user
> who won't be using serialization capabilities shouldn't be
> forced to explicitly disable autolinking.

OK, I didn't think about this.  But now that I do, I'm still not convinced
there's a problem.  I would suppose that the example you cite would be
equivalent to including a library on the command line that contains no
symbols that the source code refers to.  That is, auto-linking might require
that the library be searched but if no compiled code referred to any thing
actually in the library, no library code would actually be added to the
user's executable.  This is similar to the situation in that with VC 7.1 the
default link setup specifies a whole group of libraries we never use.
(ole.lib and ?) But they don't end up adding code to our programs.

And another thing.  In the serialization library, the #include auto-link
header is only included when one includes the *_?archive.hpp headers.  So I
don't see the question comming up at all.

The serialization library is sort of three-headed monster.  One head is
based on templates which are expanded in the users program at compile time.
The other head is runtime code for common functions.  The third head is code
instantiated by templates for specific archive types and this code is
included in the libraries.  Autolink headers are invoked for only the
sencond and third heads

Robert Ramey