Re: [boost] [serialization] new STATIC_ASSERTION_FAILURE

From: David Abrahams (dave_at_[hidden])
Date: 2005-06-24 08:33:27

Martin Bonner <martin.bonner_at_[hidden]> writes:

> ----Original Message----
> From: Robert Ramey [mailto:ramey_at_[hidden]]
> Sent: 23 June 2005 17:07
> To: boost_at_[hidden]
> Subject: Re: [boost] [serialization] new STATIC_ASSERTION_FAILURE
>
>> Vladimir Prus wrote:
>> 
>>>> "all #includes from the boost/archive directory should preceed all
>>>> #includes from the serialization directory."
>>> 
>>> This rule means that I can't include
>>> <boost/serialization/base_object.hpp>
>>> in my headers, and then in my cpp file first include my headers and
>>> then archive headers. And I do want to include my header first in
>>> .cpp, in order to detect any missing includes in the header itself.
>> 
>> I don't really understand this.
>
> Many people (myself included) have a rule that header files are self
> contained.  If you need something in the header file, you #include the
> header and that is all you have to do.  To police this, and to make sure
> that the program is not compiling "by accident" because every current
> occurance of the header happens to be preceded by the required headers, the
> standard form of a file xxx.cpp in my projects is:
>   #include "universal.h" // Absolutely standard includes that would be 
>                          // boring to include in every header - like
> windows.h
>   #include "xxx.h"       // Prove that xxx.h is self contained.
>
> Some people have an even stronger form of the rule without the universal.h -
> they will have a REAL problem with requiring an order of includes.
>
> I read your explanation of why you have the requirement on the order of
> includes, and it seems to buy some advantages for some people (but not all).
> It *is* quite a high cost though; not having used serialization, I can't say
> whether it is worth it.

Even if you don't like that technique, in a world with headers
including other headers, #include order is notoriously hard to control
and maintain.  Any design that relies on it is fragile.

I know this from personal experience because Python has such a rule
and it messes up my Boost.Python developers all the time.
Incidentally, I believe Python's rule is imposed on it by POSIX :(

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com