Re: [boost] Type_traits library/MSVC8 intrinsics : bug

From: Thyfate (thyfate_at_[hidden])
Date: 2006-04-20 07:14:49

Thanks for your concern John. Type traits is one of the boost libraries
which are most useful to me, and let me thank you and the boost team for it
by the way.

I am not sure I understand your point about the __has_trivial_constructor
intrinsic being broken... it seems to work pretty fine to me ?

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

As far as I am concerned, I patched boost/type_traits/intrinsics.hpp by
commenting out the __is_pod intrinsic, and now everything seems working
fine.

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 information.

Perhaps it would be possible to rebuild a non-broken is_pod using compiler
information, based only on the other intrinsics ?

Thanks,

Charles-Antoine Giuliani

-----Original Message-----
From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
On Behalf Of John Maddock
Sent: jeudi 20 avril 2006 11:58
To: boost_at_[hidden]
Cc: Jason Shirk
Subject: Re: [boost] Type_traits library/MSVC8 intrinsics : bug

> The following program compiled with MSVC8 gives different results
> between intrinsics and boost type traits (in the wrong sense: as if
> the type traits library knew more about the classes than the compiler)
>
> It seems to me this is related to a bug in MSVC8 intrinsics which
> should not consider class two (see program below) as a POD type...
> The library should thus not use the __is_pod intrinsics... though I
> can not find in the
> standard a place where it is said that POD types should not have
> constructors... (but then class one should also be of pod type)
>
> Could someone please confirm/propose a fix?

I can't believe I left this one so long in my todo box before I spotted it 
again: sorry!

You're quite right that __is_pod does appear to be buggy in this respect. 
I've done some more experimenting and it appears that:

If the class "one" in your test:

* has an explicit destructor, everything is OK.
* has an explicit copy-constructor everthing is OK.
* has an explicit assignment operator everything is OK.

But if it has an explicit default constructor, even one with side-effects as

your example shows, then it wrongly lables classes that encapsulate "one" as

a POD.

It's worse too: has_trivial_constructor has the same problem: classes that 
clearly do not have trivial constructors get wrongly labled as such (class 
"two" in your test).

Darn, this is a problem, I think we're going to have to disable those two 
intrinsics for the next release.  If we don't and 
has_trivial_constructor/is_pod are used to optimise-away constructor calls 
(one of their intended use case), then potentially calls to constructors 
with side effects will be omitted.

Aside: I'm surprised that this matches VC++'s internal notion of POD-ness, 
doesn't that cause optimiser bugs in cases like this - destructors not being

called when they should be?  If not what use is this trait to anyone?  I'm 
sure I must be missing something here given that I haven't actually seen 
VC++ to get this wrong when optimising ....

Anyone else any thoughts?

Thanks,

John.

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost