RE: [boost] Re: type_trats testing was([type traits] Docnitpick&a dd_referencequestion)

From: Rozental, Gennadiy (gennadiy.rozental_at_[hidden])
Date: 2002-10-04 14:56:36

> I like the above very much. However, it's going to be 
> difficult to use for
> some cases, like those in the type traits library, which run 
> a suite of
> checks with a variety of types. The problem is that on some 
> compilers, a
> given trait will work fine, e.g., for everything but pointers to
> const-volatile-qualified member functions. That doesn't make the trait
> completely broken on that platform -- not at all. The problem 
> is that type
> traits are SO useful for getting around the limitations of 
> broken compilers
> that we don't want to just say "this one works"/"this one doesn't".
> Instead, it's important to tease apart just what the behavior 
> of each one
> is.

One thing to do is to separate the basic and andvanced features. Second you
could alwats use detailed report that will produce the assertion based
information so you will have a complete picture.

FWIW you gave a positive feedback (does anybody else have any other
propositions). I will try to implement it some time soon.
 
> I'm not as fond of this part of your proposal. One problem is that if
> something happens which causes a previously-non-compiling 
> test to start
> compiling, nothing will tell you because nothing ever tries 
> to compile it.
> I think we'd better deal with this differently, and it we'll 
> need to take a
> long-term view. Probably some kind of script-driven system 
> will be most
> appropriate... but let's see if we can deal with the other 
> issues first.

The same issue exist with the config system in general. We define some
workarounds in here and not able to tell when we do not need them anymore.
The solution AFACT is to ise BOOST_NO_CONFIG to prevent all workarounds. The
same could be done for conditional compilation either.

Gennadiy.