Re: [Boost-users] [Serialization] 1.33 RC1 nvp.hpp gotcha

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

>>We've discussed this with you on the boost ml, and in the end result
>>you've
>> 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
indirectly.

> 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