stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <>
Subject RE: remove_reference
Date Fri, 13 Jun 2008 07:50:00 GMT

>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


View raw message