John Maddock ha escrito:
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/Messae/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.
Yes. Pavel proposes to add this informative macro and *no* workaround, so that it's up to the user to use is_abstract in defective compilers (even risking a crash) or build some internal logic to avoid it based on the macro. Thinking about it, I tend to agree with Pavel and you: returning false is not necessarily a reasonable default, so I'd go for the macro, only (and ask Robert to fix his hack in Boost.Serialization.) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo