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

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

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.

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

This is a common and widely used style. which I have in mind when I write "I 
believe that this rule should be very easy to follow" .

Given you're observations, I would probably rephrase that to "I believe that 
this rule should usually be very easy to follow"

So.  Now the question arises as to what can/should be done about this.

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.

b) I'm don't think that imposition of the code organization as exemplified 
by A.hpp is a very heavy burden.  Of course that's only my opinion.

That is the rationale for the header ordering "rule".  I can see now how 
this might conflict with some other "global style"  but I'm not sure how to 
address it without creating another problem.  That is, the imposition of 
this header ording rule was only to address a real problem for which I could 
find no better solution.

I havn't seen your code and global style.  But its hard for me to imagine a 
case where mixing archive headers and serialization headers in the same 
header file would be an attractive design choice.

That's the real motivation for  "I believe that this rule should usually be 
very easy to follow"

Robert Ramey