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

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-04-16 06:55:50

----- Original Message -----
From: "John Maddock" <john_maddock_at_[hidden]>

> I suspect that those are __int64 misconfigurations?

I don't know. What exactly do you suspect is misconfigured?

> > 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?

In this case, isn't the "To" type really only a function parameter
syntactically? If I write:

    void f(int[2])
    void g(int*)

do f() and g() have different signatures?

If so, I guess we keep it as is. Otherwise, some change is in order.

-Dave