incubator-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 Fri, 30 May 2008 23:53:28 GMT
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.
> 
> 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.

> };
> 
> template <class T>
> struct __rw_is_const_impl
> {
>   enum { _C_value = 0 };
> };
> 
> template <class T>
> struct __rw_is_const_impl<const T>
> {
>   enum { _C_value = 1 };
> };
> 
> template <class T>
> struct __rw_is_const
>   : __rw_integral_constant<bool, __rw_is_const_impl<T>::_C_value>
> {
> };
> 
> template <class T, T v>
> struct integral_constant : __rw_integral_constant<T,v>
> {
> };
> 
> template <class T>
> struct is_const : integral_constant<bool, __rw_is_const<T>::value>
> {
> };
> 
>>>> 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.

Martin

Mime
View raw message