John, now that you're at is_abstract, I wonder whether you could consider adding some workaround in is_abstract.hpp making boost::is_abstract return unconditionally false for those compilers known not to work for it. You can read about the origin of this request at:
http://aspn.activestate.com/ASPN/Mail/Message/boost/2209389
In a nutshell, Boost.Serialization does some (ODR-nonconformant) redefinition of boost::is_abstract the way I'm suggesting. These precautions are necessary because, on those compilers not supporting the is_abstract implementation, the construct can crash instead of returning false, and this makes it impossible to use the facility without carefully taking care of the compiler.
Uh, I hadn't realised that that was the case. However, here's the question: is it always true that returning false is always safe? If the user's code uses is_abstract to determine whether an actual instance of a class can exist, then won't it do the wrong thing? I can (just about) understand is_polymorphic having a safe default, but is that true of is_abstract? I suppose what I'm saying is that the users idea of what constitutes a safe default may vary from use case to use case. We should define an appropriate macro though, whatever else is decided. John.