Re: [boost] [serialization] new STATIC_ASSERTION_FAILURE

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-06-23 10:58:22

The issue isn't two-phase lookup.  That was addressed in they way you
suggest but didn't have anything to do with header order.

Header order rears it head under a couple of situations:

a) export instantiates code for all used archive types - an no others.  By
requiring that it be placed after the *archive.hpp files, it can know what
archive classes to instantiate for.

b) the default system for determining the type of a pointer is rtti.  The
system permits one to substitute his own - there is an example
extended_type_info_no_rtti.hpp .  The first one included becomes the
default.  If no non-default header has been included the first time it is
needed, the rtti one is included.

c) avoiding auto-link sometimes means avoiding instantiating code that is
not needed.  This is not a bad thing anyway.  By separating code in to
*archive modules - which inply usage of the library and auto-link and
*serialization modules which only instanciate code when *archives have been
included, it permits *serialziation modules to be included in header files
and those header files to be included in on programs that don't use
serialization library.  That is, it prevents the inclusion of serializaition
code in the header from requiring the serialization library if no
serialization is in fact being done.

So that's how we got to where we are.

I had no problem, tweaking my tests and examples to follow this rule and I
can't see a case where this would be problematic.  I'm aware that depending
on header order is an extra burden, but in this case its a very small price
to pay in exchange for the benefits recieved.

Robert Ramey

David Abrahams wrote:
> "Robert Ramey" <ramey_at_[hidden]> writes:
>
>> In order to get desired behavior regarding invocation of
>> auto-linking only when necessary I had to impose some restriction
>> regarding sequening of #include statements.  The rule is:
>>
>> "all #includes from the boost/archive directory should preceed all
>> #includes from the serialization directory."
>
> Ouch, that's pretty scary.  #include order is notoriously hard to
> control and maintain.  I'm not sure what's at play here, but I'm
> guessing it's some phase-1 name lookup issue?  Can't you move it to
> phase 2 (usually by using an unqualified call or specialization)?