Boost logo

Boost Users :

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-08-11 10:54:11

Vladimir Prus wrote:
>> The statement "I believe that this rule should be very easy to
>> follow" is definately true. I'm quite sure I know what I believe.
> Oh ;-) I kinda though that "I believe" is just a polite way of making
> a statement.

I mean to say that this is my opinion. I really do mean that, as far as I
know, based on my personal experience, demos, and test cases I believe that
organizing code subject to this rule/restriction shouldn't be difficult. I
also mean that I'm open to be proved wrong via counter example. And the
submission of such a counter example won't be taken personally in any way.

>> 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. The solution - auto-linking is that macros in the code 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. I believe this issue would occur with any
of the libraries which support auto-linking. I don't know if its an issue
with other libraries. I would expect it to be an issue only with libraries
which require that headers be included from within other headers.

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

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

Now it has come about that this creates its own set of inconveniences for
some applications. There's your case, and another has brought up
precompiled headers.

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
which support auto-linking. I had to spend a significant amount of time to
get this right and I don't relish making it more elaborate.
b) It would mean that a program which used serialization on one platform
(e.g. gcc) would not support auto-linking when moved to a platform which had
auto-linking available. As I write this, this wouldn't be so bad - just one
more section to the manual (the gotcha section) indicating that auto-linking
should be suppressed via compile time define when the application is moved.

Now someone has raised the issue of pre-compiled headers - which is a
feature that as far as I know is only available on borland and Microsoft
compilers which also support auto-linking.

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.

Robert Ramey

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