RE [Boost-announce] [Review] Boost.Type Traits Extension by Frederic Bron
What is your evaluation of the design?
Overall it is fine. However, I have two suggestions you may want to consider: a. For the assignment operators (for example +=) the name proposed is of the form has_operator_<op>_equal (for example has_operator_plus_equal). Wouldn't has_operator_<op>_assign (for example has_operator_plus_assign) be more intuitive? b. From the documentation: There is an issue if the operator exists only for type A and B is convertible to A. In this case, the compiler will report an ambiguous overload. Couldn't this be mitigated by changing the default for the result type from void to the type as in <functional>? 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.
What is your evaluation of the implementation? Good that it is a 'header only' extension.
What is your evaluation of the documentation? Has all that is required. One can start using the library after a few minutes of looking at the documentation.
What is your evaluation of the potential usefulness of the library? Very useful, on those (AFAIK somewhat rare) occasions when it is required.
Did you try to use the library? With what compiler? Did you have any problems? Briefly used it with g++ 4.5.0 on both FreeBSD and Linux. Tested only a few Operator Type Traits, and had no problems whatsoever.
How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A quick reading.
Are you knowledgeable about the problem domain? Not really. I'm just a journeyman programmer who has found the Type Traits library useful in the past.
Do you think the library should be accepted as a Boost library? YES.
a. For the assignment operators (for example +=) the name proposed is of the form has_operator_<op>_equal (for example has_operator_plus_equal). Wouldn't has_operator_<op>_assign (for example has_operator_plus_assign) be more intuitive?
Why? is it to avoid confusion with "equal to"? I like plus_equal because plus is a sign and equal is also a sign too. So I think it is easier to remember.
b. From the documentation: There is an issue if the operator exists only for type A and B is convertible to A. In this case, the compiler will report an ambiguous overload. Couldn't this be mitigated by changing the default for the result type from void to the type as in <functional>?
This is not related to the return type. Only to the arguments of the operator.
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<double, int> would then check for a return type "double" while has_operator_plus<int, double> for a return type int. You would break the symmetry of these operators. Also what about dereference operator? Regards, Frédéric
Why? is it to avoid confusion with "equal to"? I like plus_equal because plus is a sign and equal is also a sign too. So I think it is easier to remember.
I also tend to vocalize += as 'plus equal'. I suggested plus_assign because of the assign member function provided by standard containers.
This is not related to the return type. Only to the arguments of the operator.
Oh, I see.
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.
I see your point. And there is also an issue with derived class to base class conversion, where the base class may have overloaded an operator.
has_operator_plus<double, int> would then check for a return type "double" while has_operator_plus<int, double> for a return type int. You would break the symmetry of these operators. Also what about dereference operator?
Yes, it has been a perennial issue. Like in std::max<int,double>. Unfortunately there doesn't seem to be a universally satisfying solution. Fortunately, it is not a first order issue; one can always refuse to use the default for the result type. Thanks and regards Vijayan
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<double, int> would then check for a return type "double" while has_operator_plus<int, double> for a return type int. You would break the symmetry of these operators.
User wanting symmetry could use common_type<LHS,RHS> 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. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/RE-Boost-announce-Review-Boost-Type-Trait... Sent from the Boost - Dev mailing list archive at Nabble.com.
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<double, int> would then check for a return type "double" while has_operator_plus<int, double> for a return type int. You would break the symmetry of these operators.
User wanting symmetry could use common_type<LHS,RHS> 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... - Jeff
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<double, int> would then check for a return type "double" while has_operator_plus<int, double> for a return type int. You would break the symmetry of these operators.
User wanting symmetry could use common_type<LHS,RHS> 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<A,B>::type undefined? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/RE-Boost-announce-Review-Boost-Type-Trait... Sent from the Boost - Dev mailing list archive at Nabble.com.
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<double, int> would then check for a return type "double" while has_operator_plus<int, double> for a return type int. You would break the symmetry of these operators.
User wanting symmetry could use common_type<LHS,RHS> 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<A,B>::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
Jeffrey Lee Hellrung, Jr. wrote:
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<double, int> would then check for a return type "double" while has_operator_plus<int, double> for a return type int. You would break the symmetry of these operators.
User wanting symmetry could use common_type<LHS,RHS> 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<A,B>::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...
Yes, this could be a good default, but we don't have it yet :( Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/RE-Boost-announce-Review-Boost-Type-Trait... Sent from the Boost - Dev mailing list archive at Nabble.com.
participants (4)
-
Frédéric Bron -
Jeffrey Lee Hellrung, Jr. -
Vicente Botet -
vijayan