stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: remove_reference
Date Fri, 13 Jun 2008 08:31:35 GMT
Travis Vitek wrote:
>  
> 
>> 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<>.

Yes. We both forgot what we had discussed. We need to write these
things down.

> 
> 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

FWIW, it might be worth waiting until it's been ported to other
compilers besides MSVC to see if it still makes sense and/or if
there is a better way to do it.

Martin

Mime
View raw message