David Abrahams ha escrito:
Joaquín Mª López Muñoz wrote:
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.)
It seems to me that true is the appropriate safe default for is_abstract. Am I missing something?
So that generic code won't try to instantiate an abstract type? Is this your rationale? Well, maybe. In the case of Boost.Serialization, however, I think that the appropriate default is false, since serializating (types derived from) an abstract type is more difficult than the non-abstract case. Either way, if we have a BOOST_NO_IS_ABSTRACT (for instance) macro, the programmer can choose whether to rely on is_abstract's default of not. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo