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.