incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <>
Subject RE: type_traits progress
Date Sat, 31 May 2008 00:27:51 GMT

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.

Can you think of a reason why this 'feature' would be important?

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

Actually, this was originally a typo on my part, but I do see where this
is going. I haven't read about template typedefs, but it seems that
there would be a serious problem caused by the cyclic dependency.

>> };

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

I'm starting to think that the above example is not motivating at all.
There is no reason that any of our library code would ever need to use
the public types because those types are just alternate names for the
internal implmentation types. If we are writing code to be used in other
parts of our implementation, then we would always use the internal _C_


View raw message