Boost logo

Boost :

Subject: Re: [boost] RE [Boost-announce] [Review] Boost.Type Traits Extension by Frederic Bron
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2011-03-15 15:46:38


On 3/15/2011 7:28 AM, Vicente Botet wrote:
>
> Jeffrey Lee Hellrung, Jr. wrote:
>>
>> On 3/15/2011 3:00 AM, Vicente Botet wrote:
>>>
>>> Frédéric Bron wrote:
>>>>
>>>>
>>>>> For example:
>>>>> has_operator_unary_minus< class RHS, class RET=RHS>
>>>>> has_operator_minus_assign< class LHS, class RHS=LHS, class RET=LHS>
>>>>> This would take care of most of the normal use cases.
>>>>
>>>> I think it is best to have the default behavior to forget about the
>>>> return type. Why would you impose return type to be LHS?
>>>> It is fine for +, -, ... when RHS=LHS but when you start to deal with
>>>> different types, I think it just adds confusion.
>>>> has_operator_plus&lt;double, int&gt; would then check for a return type
>>>> "double" while has_operator_plus&lt;int, double&gt; for a return type
>>>> int.
>>>> You would break the symmetry of these operators.
>>>>
>>>
>>> User wanting symmetry could use common_type&lt;LHS,RHS&gt; in this case.
>>> But
>>> using it as default is not good idea as common_type is not always
>>> defined.
>>> So I agree to change the default behavior to don't check.
>>
>> When is common_type not defined? I see no documentation in
>> Boost.TypeTraits.CommonType mentioning it not being available for
>> certain compilers...
>>
>
> I was not talking about compiler restrictions, but of non existence of a
> common type to two unrelated classes or I'm yet missing something.
>
> Given
>
> class A{};
> class B{};
>
> isn't common_type&lt;A,B&gt;::type undefined?

Oh, of course, I should have guessed that's what you meant...my apologies :/

One could, instead of using common_type directly, use a variant, e.g.,
common_type_or_void, that evaluates to void if A and B have no common
type. I don't know if such a metafunction is possible or worth it,
though...

- Jeff


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk