-----Original Message----- From: narechk [mailto:narechk@gmail.com] Sent: Wednesday, July 13, 2005 10:29 AM Subject: Re: VC8 type traits documentation
It appears the support for compiler intrinsic type traits in Beta2 is implemented only partially:
typedef int T; __is_pod(T); __has_trivial_constructor(T); __has_trivial_copy(T); __has_trivial_assign(T); __has_trivial_destructor(T); __has_nothrow_constructor(T); __has_nothrow_copy(T); __has_nothrow_assign(T);
Ditto for the rest of fundamental types. All of the above return false, which AFAIK is incorrect! [§3.9, ¶10; §9, ¶4]
The compiler intrinsics are only there to provide the type information that is otherwise unavailable. Put another way, for fundamental types, we decided we don't care what the value is (we default to false) since an implementation of type traits can get the right value. This simplifies the implementation and puts the burden on the library implementation which can change more easily than the compiler.
struct A { A() {} A(const A&) {} const A& operator=(const A&) {} };
typedef A T; __is_pod(T); // false __has_trivial_constructor(T); // false __has_trivial_copy(T); // false __has_trivial_assign(T); // false __has_trivial_destructor(T); // true __has_nothrow_constructor(T); // false, too conservative __has_nothrow_copy(T); // false, too conservative __has_nothrow_assign(T); // false, too conservative
The compiler is too conservative regarding nothrow, it should be able to deduce that constructor, copy and assign can never throw.
struct B { B() throw() {} B(const B&) throw() {} const B& operator=(const B&) throw() {} };
typedef B T; __is_pod(T); // false __has_trivial_constructor(T); // false __has_trivial_copy(T); // false __has_trivial_assign(T); // false __has_trivial_destructor(T); // true __has_nothrow_constructor(T); // true __has_nothrow_copy(T); // true __has_nothrow_assign(T); // true
It seems the compiler needs an explicit nothrow statement in order for ctor, copy and assign to be qualified as nothrow. Presumably the result of nothrow deduction is not fed to the intrinsics correctly in this version.
Can someone comment on the above.
You are correct that the compiler _could_ deduce nothrow in your example, but in general the compiler couldn't (for example, if the definition of the function is in the current translation unit), and therefore shouldn't try. -- Jason Shirk VC++ Compiler Team