Re: [boost] Re: is_convertible corner case

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2003-01-24 21:12:01

On Friday, January 24, 2003, at 08:32  PM, David Abrahams wrote:

> Actually, not that it matters, but I think I'm misquoting the original
> request, which was, IIRC, "tell us whether evaluating this expression
> should produce a compilation error."  Howard knows for sure...

Yes, that was my proposal, and yes, it made compiler writers very 
nervous.

is_convertible is fragile.  I suspect that it may end up needing 
compiler support to really implement in a rock solid manner.  That 
being said, it is amazingly useful in its current form and I've only 
bumped up against its fragility once:

struct A
{
private:
    A(const A&);
};

struct B
: A
{
};

char test[is_convertible<B, A>::value];

On Metrowerks this gives:

Error   : illegal access from 'A' to protected/private member
'A::A(const A &)'
(instantiating: 'is_convertible<B, A>')
main.cpp line 14   tatic const bool value =
sizeof(is_convertible_helper<U>::test(make<T>())) == 1;

whereas on Comeau it will compile.  At issue is what happens when you
pass a non-POD class through an ellipsis.  We copy the class via its
copy constructor.  Apparently Comeau doesn't.  5.2.2/7 says the
behavior is undefined.  Apparently we make an attempt to deal with
non-POD classes in our va_arg system.

Fortunately circumstances such as the one illustrated above seem to be 
rare (at least in my experience).  But it is amusing (amazing?) how 
many traits like tests are today passing non-POD classes to an 
ellipsis, and invoking undefined behavior! :-)

-Howard