Re: [boost] Re: additional test for is_abstract type trait

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2004-11-30 06:52:29

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