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

From: John Maddock (john_at_[hidden])
Date: 2006-04-20 05:58:22

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