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 11:48:32

David Abrahams ha escrito:

> Joaquín Mª López Muñoz wrote:
> >
> > David Abrahams ha escrito:
> >
> >> 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?
>
> Yes.
>
> > 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.
>
> But serialization can always check the macro.  The standard practice for
> type traits that need some compiler support is to degrade gracefully
> (code still compiles) and safely (only the most conservative assumptions
> are made).  Why shouldn't we do that in this case?

Yes, maybe. I don't have more arguments in favor of either option
that I've already given, so defaulting to true will be just fine too (if
documented). What I'd like to have is the macro, as I said,
so that the hack at Boost.Serialization can be taken care of.

(Not that I abhor of hacks, the problem with the current one is that
it is dependent on the order of header inclusions. I'm surprised that
no user has reported this yet.)
(I've searched the web for real-world use cases of is_abstract that
can help us decide about the best default value. Turns out I've found
no code using it except Boost.Serialization.)

>
>
> > 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.
>
> Yes, but that's a different issue.

?? By BOOST_NO_IS_ABSTRACT I mean a config macro telling
whether DR337 is supported. It's the same issue, or else I'm not getting you.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo