Re: [boost] Re: [serialization] automatic linking andintrusiveserialization support
----- Mensaje original ----- De: Robert Ramey <ramey@rrsd.com> 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. Get my point? If so, and if you agree with my analysis, do you think the workaround I propose would work? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
JOAQUIN LOPEZ MU?Z wrote:
----- Mensaje original ----- De: Robert Ramey <ramey@rrsd.com> 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
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
participants (3)
-
JOAQUIN LOPEZ MU?Z -
Joaquín Mª López Muñoz
-
Robert Ramey