Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates
 72.14.220.155 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding:sender;
        b=b/Fd1rVBSjAmzwLnAiuP8HPaAGkjXIRIqkI1cQmqwtb0yB8jALwXRfCYfGG0/Ldcct
         OOYmafCOPZCO8kWNGp0GicNebPdlW/6/x1kiaH7i5CZJam/nV0YLyioq3DUL5XeSA7E5
         0aN7jceD5HtXyrxMpcnWrqX9eHfK0OpAOK1vs=
Message-ID: <48523067.8040401@roguewave.com>
Date: Fri, 13 Jun 2008 01:31:35 -0700
From: Martin Sebor <sebor@roguewave.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: Re: remove_reference
References: 
 <CFFDD219128FD94FB4F92B99F52D0A49010A3841@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA89D@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A3844@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA8A0@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A3846@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA8A1@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A3847@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA8A3@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A384C@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA8A5@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A384E@exchmail01.Blue.Roguewave.Com>
 <485220EE.8060702@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA8A6@exchmail01.Blue.Roguewave.Com>
In-Reply-To: 
 <CFFDD219128FD94FB4F92B99F52D0A499AA8A6@exchmail01.Blue.Roguewave.Com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Martin Sebor <msebor@gmail.com>

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