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
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
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk