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 07:25:34 GMT
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.

Martin

Mime
View raw message