Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk