On Friday, January 24, 2003, at 08:32 PM, David Abrahams wrote:
Yes, that was my proposal, and yes, it made compiler writers very nervous.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...
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
