Return-Path: 
 <dev-return-7829-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org>
Delivered-To: apmail-stdcxx-dev-archive@www.apache.org
Received: (qmail 80461 invoked from network); 11 Jun 2008 22:47:52 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 11 Jun 2008 22:47:52 -0000
Received: (qmail 82737 invoked by uid 500); 11 Jun 2008 22:47:55 -0000
Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org
Received: (qmail 82722 invoked by uid 500); 11 Jun 2008 22:47:55 -0000
Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@stdcxx.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@stdcxx.apache.org>
List-Post: <mailto:dev@stdcxx.apache.org>
List-Id: <dev.stdcxx.apache.org>
Reply-To: dev@stdcxx.apache.org
Delivered-To: mailing list dev@stdcxx.apache.org
Received: (qmail 82711 invoked by uid 99); 11 Jun 2008 22:47:55 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Jun 2008 15:47:54 -0700
X-ASF-Spam-Status: No, hits=2.6 required=10.0
	tests=DNS_FROM_OPENWHOIS,SPF_HELO_PASS,SPF_PASS,WHOIS_MYPRIVREG
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Jun 2008 22:47:04 +0000
Received: from isper.nabble.com ([192.168.236.156])
	by kuber.nabble.com with esmtp (Exim 4.63)
	(envelope-from <lists@nabble.com>)
	id 1K6Z69-0006Dd-Om
	for dev@stdcxx.apache.org; Wed, 11 Jun 2008 15:47:21 -0700
Message-ID: <17788935.post@talk.nabble.com>
Date: Wed, 11 Jun 2008 15:47:21 -0700 (PDT)
From: Travis Vitek <vitek@roguewave.com>
To: dev@stdcxx.apache.org
Subject: Re: type_traits progress
In-Reply-To: <48409378.3010407@roguewave.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Nabble-From: vitek@roguewave.com
References: 
 <CFFDD219128FD94FB4F92B99F52D0A499AA862@exchmail01.Blue.Roguewave.Com>
 <483B79A1.4070808@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA864@exchmail01.Blue.Roguewave.Com>
 <483C67BA.6070209@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA86C@exchmail01.Blue.Roguewave.Com>
 <48401E00.2090709@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA86D@exchmail01.Blue.Roguewave.Com>
 <48409378.3010407@roguewave.com>
X-Virus-Checked: Checked by ClamAV on apache.org




Martin Sebor wrote:
> 
> Travis Vitek wrote:
> [...]
>>> Right. That could be another wrinkle. Our traits won't
>>> work with generic code that takes integral_constant<T, V>
>>> by reference.
>> 
>> I don't really see the motivation, but it is obvious that the committee
>> thought it was important for the standard traits to do so, so we should
>> probably follow suit in our internal implementation.
> 

I read the proposal for type traits and their motivation for using the base
class integral_constant<T,V> is to avoid having to write out of line
definitions as well as inline initialization of the static const member for
every trait.


Martin Sebor wrote:
> 
>> 
>> If we did decide to do this then we would probably want our own write
>> __rw_integral_constant and use that internally to avoid namespace
>> pollution? Then I'd assume we'd want something like the following
>> example for is_const...
> 
> Yes, I think this is close to what we want. The only thing that bugs
> me about it is...
> 
>> 
>> template <class T, T v>
>> struct __rw_integral_constant
>> {
>>   static const T value = v;
>>   typedef T value_type;
>>   typedef integral_constant<T,v> type;
> 
> ...this backward dependency on integral_constant, but I don't see how
> to break it without template typedefs. I don't think there's a compiler
> out there that supports them yet.
> 
>> };
>> 
>> 
>>>>> Another, and probably far more important reason for keeping the
>>>>> names of the members the same, to make our implementation traits
>>>>> look and feel like standard traits, i.e., conform to the traits
>>>>> requirements. Otherwise the rest of our library won't be able
>>>>> to easily use the private traits.
>>>> But this should only be an issue if we are passing around traits as
>>>> template parameters, right?
>>> Right.
>>>
>>>> All of the scenerios I can think of we would be using 
>>> __rw_enable_if or
>>>> specialization on non-type template parameters. Can you think of any
>>>> case where the name of the member would be important?
>>> I searched the latest draft standard to see if traits were
>>> being used anywhere in the spec but didn't get any hits.
>>>
>>> I hadn't thought too deeply about how the traits could be
>>> used, but I have used traits outside of enable_if. I think
>>> its should be easy to contrive code that wouldn't work with
>>> our approach. Let me try:
>>>
>>>     // transforms T if it satisfies Property<T>
>>>     // by applying Transformer<T>, otherwise leaves
>>>     // T unchanged:
>>>
>>>     template <class T,
>>>               template <class> Property,
>>>               template <class> Transformer>
>>>     struct TransformIf;
>> 
>> Yes, if we go with the above approach then this problem just disappears
>> for any trait inheriting from __rw_integral_constant. For the other
>> types I can just expose the names that the standard defines.
>> 
>> I'm okay with that if you think that the motivation is there.
> 
> I'm not sure the contrived example I gave qualifies as a motivating
> use case but it is a use case nonetheless. That said, I don't think
> consistency with other uglified names is a compelling enough reason
> for us to dismiss even this contrived use case.
> 

As I mentioned in a previous message in this thread, I see no reason why the
above wouldn't work with our current approach.

  template <class T,
            template <class> Property,
            template <class> Transformer>
  struct __rw_transform_if
  {
      typedef typename
      __rw_conditional<Property<T>::_C_value,
                       T,
                       Transformer<T>::_C_type>::_C_type _C_type;
  };

Every one of the required traits have internal implementations, so any code
that would be be written using required traits could be written using the
internal ones. If the trait above was intended to be part of the
implementation, then it would appear in the __rw namespace and it would use
the internal traits. If it were intended to be part of the public interface,
then it would be in the appropriate namespace and it would use the required
traits.

So I don't see any motivation to use the same names as required by the
standard for the internal types. For the same reasons, I don't understand
why integral_constant<T,V> should interit from __rw_integral_constant<T,V>.

Travis
-- 
View this message in context: http://www.nabble.com/type_traits-progress-tp17442721p17788935.html
Sent from the stdcxx-dev mailing list archive at Nabble.com.