Re: [boost] type_traits (and test lib): state of the union

From: John Maddock (john_maddock_at_[hidden])
Date: 2002-04-16 06:32:22

Dave,

Sorry for the delay in getting back to you, my mail is getting backed up :-(

> 1. With various windows compilers I have at my disposal, the type_traits
> library tests are reporting unexpected failures. For example:
>
> Intel C++ 5.0 atop VS6:
>
> *
> ***************** failed above test: arithmetic_traits_test
> ********************
> 128 tests completed, 12 failures found, 0 failures expected from this
> compiler.
>
>
> Intel C++ 6.0 atop VS.NET:
>
> *
> ***************** failed above test: arithmetic_traits_test
> ********************
> 128 tests completed, 12 failures found, 0 failures expected from this
> compiler.

I suspect that those are __int64 misconfigurations?

>
> 2. I am still really confused by the relationship the expected failures
> numbers in the test .cpp files have to the number of expected failures
> actually reported. They don't seem to match up. I am also confused about
> what the methodology should be for deciding that a test failure is
> "expected", and what our response should be when unexpected failures
> show up. I know we talked about this before, but I never got clear.
> What's the procedure to be?

Well the proceedure is that it sucks, but I haven't found anything better...

Really I suppose that there are three kinds of failures:

1) Stuff that gets skipped cos it doesn't compile.
2) Stuff for which there is no impliementtion on conforming compilers
(is_POD say), this is epected to fail everywhere (for now)
3) Stuff that should work, but doesn't, if it's been checked as a compiler
bug, and there is no known workaround, then lable it as an expected failure.

I guess I really need to separate these three cases and report the results
of each - expected failures would apply to (3) only.

>
> 3. A few of the tests seem to rely on non-conforming behavior:
> is_convertible<T,U>::type should not compile on a conforming compiler
> when T is non-copyable, but most compilers seem to accept it anyway. The
> major culprits are:

I think there may be a fix for that - see the is_convertible implementation
for gcc - I haven't tried applying this to other compilers though.

> 4. That leaves us with one failure for CWPro8:
>
>     checking value of (boost::is_convertible<int*,
> int[2]>::value)...failed
>
> It's not clear to me that this one should really succeed. How do you
> convert a pointer to int into an array of two ints?

Good question, if the "To" type is a function parameter, then it should
work, all other cases would not though.  What should we do here?

John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm