incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <Travis.Vi...@roguewave.com>
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
#endif

>Martin
>

Mime
View raw message