|
Boost Users : |
From: scleary_at_[hidden]
Date: 2002-10-15 10:11:00
> -----Original Message-----
> From: Edward Diener [mailto:eddielee_at_[hidden]]
>
> > > From: Edward Diener [mailto:eddielee_at_[hidden]]
> > >
> > > What does it mean in the type_traits documentation that "direct
compiler
> > > support for that traits class is required" ? I do not see that
terminology
> > > explained anywhere and am lost as far as to what it refers.
> >
> > It means that there is no known way to implement that class (in a
> > Standard-compliant, portable manner).
> >
> > The type traits library is in a rather uncomfortable position, since it
is
> > essentially trying to add reflection to the C++ language after the fact.
> >
> > As currently implemented, the type traits library bends over backwards
to
> > try to provide as much as possible to as many different compilers as
> > possible. But the simple fact is that it should not really be a
library,
> > but a part of the supplied language.
> >
> > Some type traits classes technically require compiler support. However,
> > those classes will all try to take their "best guess" at the correct
answer
> > -- sometimes defaulting to a "safe" default if they can't figure out the
> > correct answer.
>
> What sort of compiler support is being talked of here, since you mention
> that it can't be done in a standard-compliant manner ? Does this mean
> looking at preprocessor defines to determine the correct results, or what
?
> It is the vagueness of the term "compiler support", which you did not
> alleviate in your answer, which I am trying to clarify.
"Compiler support" means "anything the compiler can give us so that we can
implement that class correctly".
It could be a specially-recognized preprocessor define, a quasi-class (e.g.,
SGI's type traits), a pragma, a keyword, or anything else that the compiler
provides.
-Steve
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net