Boost logo

Boost Users :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-08-11 03:22:08

Robert Ramey wrote:

> Vladimir Prus wrote:
>> Robert Ramey wrote:
>>> Richard Jennings wrote:
>>>> I have found that the requirement that no serialization headers can
>>>> be included before any archive headers means that you have to be
>>>> careful which serialization headers you include in your class
>>>> headers and indeed in what order you include them.
>>> It is my intention that this issue be addressed with the simple rule:
>>> "all headers from the serialization directory should follow and
>>> headers from the archive directory"
>>> I believe that this rule should be very easy to follow.
>> You keep on making this statement, which is simply false.
> 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

>>We've discussed this with you on the boost ml, and in the end result
>> told that I should drop my design practice of including my headers
>> first in implementation files, before any system and boost headers.
>> That's basically a global change in style, and not so "easy to follow".
> The basic problem that has come up is the following:
> A.hpp
> ====
> #include some serialization headers export, nvp, etc.
> class A {
> serialize(..)
> };
> 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

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

- Volodya

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