Boost logo

Boost Users :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-08-12 03:17:44

Robert Ramey wrote:

>>> Before implementing this rule, any program which included A.hpp would
>>> require linking with the serialization library to build. This was
>>> provoked
>>> by the auto-linking facility. This would occur even if serialization
>>> wasn't
>>> used in the program. The made it amost impossible to have a
>>> "library" of classes which could be imported into various programs.
>> I don't get this. Why including <serialization/export.hpp> forces
>> auto-linking? You can arrange the headers to that auto-linking is
>> enabled only if user includes headers that require cpp files, no?
>> Specifically, you should make sure that
>> boost/serialization/config.hpp (that triggers auto-linking), is not
>> included by export.hpp, either directly or indirectly.
> ...\more\separate_compilation.html describes the problem.
> Now if I recall, you're using gcc which doesn't support auto-linking so
> you
> would never see this problem. This addresses the seeming endless problems
> that users have getting their projects to link with the proper version of
> the library. <....>

Yes, I know both the problem and what's autolinking is about.

> invoke
> #pragmas which add data to the object files which indicate which libraries
> to include. These pragmas are invoked from the auto-linking header files
> regardless of whether or not there are unresolved references to one of the
> libraries. So just including a header file which uses auto-linking would
> trigger the requirement of a library being included in the link even
> though
> the library isn't actually used.

Yes, sure, unless you clearly decide which headers require linking and which
not, and include the internal header with #pragma only from the header of
the first kind. Yes, it can be *extra* messy, but for
serialization/base_object.hpp or for serialization/nvp.hpp this should not
be very hard.

>>> a) I'm very much in agreement with the idea that the meer inclusion
>>> of a header shouldn't trigger the requirement of compilation against
>>> a library which isn't used. I realize that this is only a problem
>>> on compiles which support some sort of auto-link pragma.
>> I don't see how header order affects this. Can you elaborate?
> In addressing this it occured to me that in the case where only a
> serialization header is included, it would be safe and desirable to skip
> over those parts of the headers which provoke auto-linking. This seemed
> very natural. It did imply that that any archive classes precede those
> headers. So it seemed simple and natural to generalize the "rule" already
> required by export.hpp. I really had in mind the usage scenario that was
> most common to me - that no header would include both archive and
> serialization headers. I didn't occur to me that this might cause a
> problem.
> The same "trick" is used by export to instantiate code for all archives
> and
> only those archives which have been previously included. The only
> alternatives I saw were:
> a) instantiate code for all archives - code bloat.
> b) require some sort of of defines or other user indicator as to which
> archives code should be instantiated for. This would be another hoop to
> jump through.
> So I opted for identifying the list of included archives as the list for
> which code should be instantiated for. The required that all archive
> classes precede the export.hpp.

Oh.. Okay, I think I'm starting to understand what's going on.
1. For BOOST_EXPORT used in headers, you want the list of archive classes
2. So, you want archive headers to be included before the header that
3. You generalize the above requirement to "all archive headers must be
included before all serialization headers".

Is my understanding correct?

If so, then I'd say this:
1. I don't have any magic solution for "archive headers must be included
before BOOST_EXPORT" problem. One possibility would be to disallow
BOOST_CLASS_EXPORT in headers -- after all exporting makes sense only for
concrete classes (non-abstract), and so they have some code, and some .cpp
module to invoke BOOST_CLASS_EXPORT there. Another would be to
auto-register with polymorphic_archive as I've suggested previously. (Oops,
I think I forgot to reply to your last post on that topic).

2. I'm not really happy with generalization. I still believe (although may
be wrong), that including <serialization/nvp.hpp> and many other
<serialization/> headers is possible without invoking auto-linking. Since
not users want BOOST_CLASS_EXPORT at all, or want it in headers, this will
reduce the number of "what's up with header" order questions you get on
this list.

> The auto-linking headers do contain a switch to turn off auto-linking.
> Perhaps even more attractive might be that this header inclusion rule be
> dependent on whether auto-linking is supported. On the gcc compiler -
> this
> would always be off. The concerns I would have about this are:
> a) it might mean an extra layer of complication in the serializaton
> headers

Sorry, but it seems that the BOOST_CLASS_EXPORT issue exists regardless of
auto-linking, no?

> This is making my head hurt.
> So I'm not insensitive to your concerns. Its just that, like everything
> else, something simple ( just implement auto-link)
> a) turns out to be alot more complex than it starts out. Autolink for
> serialization required treating 3 separarte but inter-related modules.
> b) has non-obvious, non-trivial side-effects.
> c) is a lot more work that it would seem.
> Writing this makes the issues a lot clearer in my own mind and I will take
> another look at it.

And seems I've finally understood your rationale.

- Volodya

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at