From: John Maddock (john_at_[hidden])
Date: 2006-04-20 13:37:58
> I am not sure I understand your point about the
> __has_trivial_constructor intrinsic being broken... it seems to work
> pretty fine to me ?
Darn, you're right, thanks for the correction.
> Boost::is_pod and boost::has_trivial_constructor become broken
> because the first one use the intrinsic and the second one use the
> first one...
Yup, that was what I was seeing.
> As far as I am concerned, I patched boost/type_traits/intrinsics.hpp
> by commenting out the __is_pod intrinsic, and now everything seems
> Most of the time, code using is_pod can be refined to be more generic
> and only use the other intrinsics. I thus managed to remove all
> is_pod uses from my code and thus still always benefit from compiler
> Perhaps it would be possible to rebuild a non-broken is_pod using
> compiler information, based only on the other intrinsics ?
Yep, just done it: change intrinsics.hpp to contain:
# define BOOST_IS_POD(T) (__is_pod(T) && __has_trivial_constructor(T))
and your test case passes now.
I need to do some more testing, but that does look like a good fix.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk