Boost logo

Boost :

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

Robert Ramey ha escrito:

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at