Re: [boost] Re: Re: [serialization]automaticlinkingandintrusiveserialization support

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2005-02-09 02:14:55

Robert Ramey ha escrito:

> JOAQUIN LOPEZ MU?Z wrote:
> > ----- Mensaje original -----
>

[...]

> > 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.

Yep, but I think the linker will try to locate the lib, even if it does
no real linking later on (after all, external symbols are searched among
all linked modules.)

>
>
> 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.

OK. So I think this closes the issue. My concern had to do with autolinking
being triggered by boost/serialization/* headers. So I guess everything'll
be fine as long as intrusive serialization support does not include any
*_?archive.hpp. Thanks for bearing with me.

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

>
>
> 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
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost