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@rrsd.com> 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)?