question re has_trivial_contructor type trait
The documentation for has_trivial_constructor has some cryptic note: Without some (as yet unspecified) help from the compiler, has_trivial_constructor will never report that a class or struct has a trivial constructor; this is always safe, if possibly sub-optimal. What does this mean - it sounds like its of new use - then why is it there? Robert Ramey
"Robert Ramey" <ramey@rrsd.com> wrote in message news:conqf6$hnh$1@sea.gmane.org...
The documentation for has_trivial_constructor has some cryptic note: Without some (as yet unspecified) help from the compiler, has_trivial_constructor will never report that a class or struct has a trivial constructor; this is always safe, if possibly sub-optimal.
What does this mean - it sounds like its of new use - then why is it there?
Certain compilers provide special information about types that can't be queried in std C++. The type traits library uses this, where possible, but always provides a conservative fallback answer. See <boost/type_traits/intrinsics.hpp> TR1 contains similar language, but the hope (I think) is that C++0x will contain enough compile-time reflection to allow these traits to be implemented 'optimally' in standard C++0x. Jonathan
"Jonathan Turkanis" wrote:
Certain compilers provide special information about types that can't be queried in std C++. The type traits library uses this, where possible, but always provides a conservative fallback answer.
OT: do you know any overview what compilers provide what kind of info? I cannot locate much in Type Traits. /Pavel
On Dec 2, 2004, at 5:50 PM, Pavel Vozenilek wrote:
"Jonathan Turkanis" wrote:
Certain compilers provide special information about types that can't be queried in std C++. The type traits library uses this, where possible, but always provides a conservative fallback answer.
OT: do you know any overview what compilers provide what kind of info?
I cannot locate much in Type Traits.
Metrowerks has provided: Metrowerks::has_trivial_copy_ctor<T>::value for a year or two now (depending on platform). Some of the STL containers use this information for optimizations. The implementation of this trait is tied to the Metrowerks compiler in a non-standard-C++ fashion (e.g. a compiler intrinsic). -Howard
On Thu, 2 Dec 2004 21:02:10 -0500, Howard Hinnant <hinnant@twcny.rr.com> wrote:
Metrowerks::has_trivial_copy_ctor<T>::value
for a year or two now (depending on platform). Some of the STL containers use this information for optimizations. The implementation of this trait is tied to the Metrowerks compiler in a non-standard-C++ fashion (e.g. a compiler intrinsic).
This is probably getting to be more standards-related than boost-related, but... Assuming it isn't proprietary information, it would be useful if you could say a little bit about what your intrinsic looks like. As you may know, the core people, especially EDG, would like to see those sorts of intrinsics standardized. Everyone is going to have to implement some kind of interface that makes type traits implementable, and the EDG people figure that everyone might as well all implement the same thing. --Matt
On Dec 2, 2004, at 9:46 PM, Matt Austern wrote:
On Thu, 2 Dec 2004 21:02:10 -0500, Howard Hinnant <hinnant@twcny.rr.com> wrote:
Metrowerks::has_trivial_copy_ctor<T>::value
for a year or two now (depending on platform). Some of the STL containers use this information for optimizations. The implementation of this trait is tied to the Metrowerks compiler in a non-standard-C++ fashion (e.g. a compiler intrinsic).
This is probably getting to be more standards-related than boost-related, but... Assuming it isn't proprietary information, it would be useful if you could say a little bit about what your intrinsic looks like. As you may know, the core people, especially EDG, would like to see those sorts of intrinsics standardized. Everyone is going to have to implement some kind of interface that makes type traits implementable, and the EDG people figure that everyone might as well all implement the same thing.
No problem. I have my doubts about needing to standardize at the language level, that's what std::libs are for: We write non-portable code so you don't have to. (that's my motto) :-) Although a de-facto, unofficial standard would certainly be convenient for us vendors. But here is a copy/paste: template <class T> struct class_has_trivial_copy_ctor { #if __MWERKS__ >= 0x3100 static const bool value = __builtin_trivial_members(T) & 0x4; #else static const bool value = false; // hook #endif }; Notes: class_has_trivial_copy_ctor is not a client level interface, has_trivial_copy_ctor is. At the class_has_trivial_copy_ctor level, T is guaranteed to be a struct or a class (not a union, scalar, reference, array, void or function) (fwiw). -Howard
OT: do you know any overview what compilers provide what kind of info?
It's an "implementation detail" in boost/type_traits/intrinsics.hpp, Currently Metrowerks and SGI provide some support. I believe that at least two other vendors have full type_traits support in the works, but I probably can't comment any more than that. John.
The documentation for has_trivial_constructor has some cryptic note: Without some (as yet unspecified) help from the compiler, has_trivial_constructor will never report that a class or struct has a trivial constructor; this is always safe, if possibly sub-optimal.
It will get the right answer for: Intrinsic types, and arrays thereof. Enums and arrays thereof. It requires compiler help for: User defined types (classes). That help is likely to become much more widespread "real soon now". John.
participants (6)
-
Howard Hinnant -
John Maddock -
Jonathan Turkanis -
Matt Austern -
Pavel Vozenilek -
Robert Ramey