>Martin Sebor wrote:
>
>Eric Lemings wrote:
>>
>>
>>> -----Original Message-----
>>> From: Travis Vitek
>>> Sent: Thursday, June 12, 2008 4:18 PM
>>> To: Eric Lemings
>>> Subject: RE: remove_reference
>>>
>>>
>>>
>>>> Eric Lemings
>>>>
>> ...
>>>> I think you sorta missed my point. My point is that if
>the internal
>>>> type traits do not provide any real added value, why bother with
>>>> them? Say you have an internal class __rw_foo and a public class
>>>> foo which derives from __rw_foo but is virtual identical, why have
>>>> __rw_foo at all? Why not move everything in __rw_foo directly into
>>>> foo?
>>>>
>>> Sorry, I understood what you were getting at, I just didn't
>>> come right out and provide the answer you were looking for.
>>> Yes, we intend to use traits in the library implementation
>>> where we can take advantage of them for performance
>>> improvements. The example I provided above is just one of
>>> many situations that we may do so.
>>
>> Performance improvements...such as taking advantage of
>built-in compiler
>> type traits? If that were the case, I could see the
>rationale for using
>> internal type traits as a proxy for such optimization. So I
>guess there
>> is SOME value after all. :)
>
>The original idea, IIRC, was to expose the implementation
>of the traits in the form of _RWSTD_XXX() macros to be used
>by the rest of our code, including the standard type traits
>template. Each macro would expand into either the compiler
>built-in for compilers that supported them or to our own
>__rw_xxx trait otherwise. The reason for this was to avoid
>paying a penalty in terms of increased compile times and
>keep the <type_traits> header free of unnecessary clutter
>when using the compiler-provided traits, as well as to avoid
>namespace pollution when using the traits.
>
So I've managed to diverge from the original idea. This is almost funny
considering all of the discussion that we had about the need for
internal traits to inherit from __rw_integral_constant<>.
Well, now that I've finally got the traits in subversion, I could go
back and 'fix' this to compile out the implementation types when the
necessary compiler support is not available. Something more like my
original implementation.
#ifndef _RWSTD_IS_POD
template <class _TypeT>
struct __rw_is_pod
{
enum { _C_value = _RWSTD_IS_TRIVIAL(_Type)
&& _RWSTD_IS_STANDARD_LAYOUT(_Type)
};
};
# define _RWSTD_IS_POD(T) _RW::__rw_is_pod<T>::type
#endif
>Martin
>
