Re: [boost] RE [Boost-announce] [Review] Boost.Type Traits Extension by Frederic Bron

Subject: Re: [boost] RE [Boost-announce] [Review] Boost.Type Traits Extension by Frederic Bron
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-03-15 10:28:39

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?
 
Best,
Vicente

--
View this message in context: http://boost.2283326.n4.nabble.com/RE-Boost-announce-Review-Boost-Type-Traits-Extension-by-Frederic-Bron-tp3353554p3356749.html
Sent from the Boost - Dev mailing list archive at Nabble.com.