So what can be done to stop these conflicts? Forcing header include orders on us isn't very practical, especially for unrelated libraries such as this (it is acceptable for the dependency order imposed between archive/serialization) as they are related) but it isn't practical in a large project to know which headers may include type_traits (directly or indirectly) and then make sure they are included after serialization headers. Thanks Russell Robert Ramey wrote:
When I look at the new code in type_traits/is_abstract for compilers which can't implement correct is_abstract, it seems it marks any polymophic class as abstract. This would conflict with the serialization system which really needs to know if a class is really abstract - not just polymorphic. I would be curious as to why type_traits/is_abstract makes this the default. The serialization system makes "false" the default.