stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: type_traits progress
Date Thu, 12 Jun 2008 08:35:14 GMT
Travis Vitek wrote:
> 
> 
> 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;
>   };

It's been some time but I think my point was that TransformIf
was an example of a trait that couldn't interoperate with both
the standard and our own private traits.

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

What is the motivation for using the name _C_type rather than
just type? The only reason we do it with other names is to avoid
clashes with user-defined macros but there can be no such macros
named type or value (not without clashing with the standard
traits).

> For the same reasons, I don't understand
> why integral_constant<T,V> should interit from __rw_integral_constant<T,V>.

I don't feel terribly strongly about this. If it turns out that
the derivation is important we can easily add it later.

Martin

Mime
View raw message