[type_erasure] default implementation of concept signatures
Hi Steve, Concepts are able to define default implementations if the type doesn't provides the specific signature. For example in 20.1.2 Comparisons the concept LessThanComparable defines a default for implementation for bool operator>(U const& a, T const& b) { return b < a; } bool operator<=(U const& a, T const& b) { return !(b < a); } bool operator>=(T const& a, U const& b) { return !(a < b); } In the definition of the concept less_than_comparable in Boost.Any, you define the implementation of these operators in function of operator<(), but if the types provide the specific signature the specific function is not called. I guess that the default implementation of for example operator<= should use operator< only if the the underlying types don't provide operator<=. What do you think? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/type-erasure-default-implementation-of-co... Sent from the Boost - Dev mailing list archive at Nabble.com.
AMDG On 05/28/2011 09:42 AM, Vicente Botet wrote:
Concepts are able to define default implementations if the type doesn't provides the specific signature. For example in 20.1.2 Comparisons the concept LessThanComparable defines a default for implementation for
bool operator>(U const& a, T const& b) { return b < a; } bool operator<=(U const& a, T const& b) { return !(b < a); } bool operator>=(T const& a, U const& b) { return !(a < b); }
In the definition of the concept less_than_comparable in Boost.Any, you define the implementation of these operators in function of operator<(), but if the types provide the specific signature the specific function is not called. I guess that the default implementation of for example operator<= should use operator< only if the the underlying types don't provide operator<=.
What do you think?
I don't think this is worth the extra complexity. Do you know of any real case where it will either a) change the behavior of a program or, b) make the program more efficient? It will definitely make the vtable larger. In Christ, Steven Watanabe
Steven Watanabe-4 wrote:
AMDG
On 05/28/2011 09:42 AM, Vicente Botet wrote:
Concepts are able to define default implementations if the type doesn't provides the specific signature. For example in 20.1.2 Comparisons the concept LessThanComparable defines a default for implementation for
bool operator>(U const& a, T const& b) { return b < a; } bool operator<=(U const& a, T const& b) { return !(b < a); } bool operator>=(T const& a, U const& b) { return !(a < b); }
In the definition of the concept less_than_comparable in Boost.Any, you define the implementation of these operators in function of operator<(), but if the types provide the specific signature the specific function is not called. I guess that the default implementation of for example operator<= should use operator< only if the the underlying types don't provide operator<=.
What do you think?
I don't think this is worth the extra complexity. Do you know of any real case where it will either a) change the behavior of a program or, b) make the program more efficient?
It will definitely make the vtable larger.
I don't know if these are real cases, but we could imagine a class that is counting the number of calls to each operator, or making some performance measures by operator, some specific logging, ... I agree that your design works most of the time, and that taking care of these specific cases needs to define several apply function in the concept (vtable), but I think that it will be really surprising for a user expecting that his specific implementation is not called. I don't think this will make the program more efficient, but more consistent. It would be unhappy if a user will not use the concepts provided by the library just due to this restriction. Anyway, if you decide to maintain your design, it will be worth documenting the behavio with the current restriction. Best, Vicente Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/type-erasure-default-implementation-of-co... Sent from the Boost - Dev mailing list archive at Nabble.com.
AMDG On 05/28/2011 11:08 AM, Vicente Botet wrote:
Steven Watanabe-4 wrote:
On 05/28/2011 09:42 AM, Vicente Botet wrote:
In the definition of the concept less_than_comparable in Boost.Any, you define the implementation of these operators in function of operator<(), but if the types provide the specific signature the specific function is not called. I guess that the default implementation of for example operator<= should use operator< only if the the underlying types don't provide operator<=.
I don't think this is worth the extra complexity. Do you know of any real case where it will either a) change the behavior of a program or, b) make the program more efficient?
It will definitely make the vtable larger.
I don't know if these are real cases, but we could imagine a class that is counting the number of calls to each operator, or making some performance measures by operator, some specific logging, ...
This is definitely going to be rare, but regardless, no algorithm using these operators is going to guarantee that it uses > instead of <. It's going to assume that it can use them interchangeably and use whichever is most convenient.
I agree that your design works most of the time, and that taking care of these specific cases needs to define several apply function in the concept (vtable), but I think that it will be really surprising for a user expecting that his specific implementation is not called.
I still don't think a specific implementation makes much sense for LessThanComparable. Currently all algorithms that require an ordering use operator< only and I haven't heard any complaints. I see the ability to use the other operators as a convenience more than anything else.
I don't think this will make the program more efficient, but more consistent.
I don't have the concepts proposal handy, but doesn't LessThanComparable have an axiom that requires that (a < b) is equivalent to (b > a)?
It would be unhappy if a user will not use the concepts provided by the library just due to this restriction.
I don't see this happening in this case. Ever.
Anyway, if you decide to maintain your design, it will be worth documenting the behavio with the current restriction.
I think it is documented. In Christ, Steven Watanabe
On Sat, May 28, 2011 at 2:55 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
I see the ability to use the other operators as a convenience more than anything else.
+1
I don't have the concepts proposal handy, but doesn't LessThanComparable have an axiom that requires that (a < b) is equivalent to (b > a)?
Yes. axiom Consistency(T a, T b) { (a > b) == (b < a); (a <= b) == !(b < a); (a >= b) == !(a < b); } -- -Matt Calabrese
On 2011-05-28 21:59:57 +0300, Matt Calabrese said:
On Sat, May 28, 2011 at 2:55 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
I don't have the concepts proposal handy, but doesn't LessThanComparable have an axiom that requires that (a < b) is equivalent to (b > a)?
Yes.
axiom Consistency(T a, T b) { (a > b) == (b < a); (a <= b) == !(b < a); (a >= b) == !(a < b); }
For what it's worth, e.g. NaN's are an exception to that rule... #include <limits> #include <iostream> #define PRINT(x) do { std::cout << #x ": " << (x) << std::endl; } while(0) int main() { double one = 1; double nan = std::numeric_limits<double>::quiet_NaN(); PRINT(one == nan); // false PRINT(one != nan); // true PRINT(one < nan); // false PRINT(one > nan); // false PRINT(one <= nan); // false PRINT(one >= nan); // false } -- Pyry Jahkola (a.k.a. pyrtsa)
AMDG On 05/28/2011 12:42 PM, Pyry Jahkola wrote:
On 2011-05-28 21:59:57 +0300, Matt Calabrese said:
On Sat, May 28, 2011 at 2:55 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
I don't have the concepts proposal handy, but doesn't LessThanComparable have an axiom that requires that (a < b) is equivalent to (b > a)?
Yes.
axiom Consistency(T a, T b) { (a > b) == (b < a); (a <= b) == !(b < a); (a >= b) == !(a < b); }
For what it's worth, e.g. NaN's are an exception to that rule...
It's not an exception. The axiom only applies to LessThanComparable types. Technically, double isn't LessThanComparable, because it violates this rule. In Christ, Steven Watanabe
On 05/28/2011 01:16 PM, Steven Watanabe wrote:
AMDG
On 05/28/2011 12:42 PM, Pyry Jahkola wrote:
On 2011-05-28 21:59:57 +0300, Matt Calabrese said:
On Sat, May 28, 2011 at 2:55 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
I don't have the concepts proposal handy, but doesn't LessThanComparable have an axiom that requires that (a< b) is equivalent to (b> a)?
Yes.
axiom Consistency(T a, T b) { (a> b) == (b< a); (a<= b) == !(b< a); (a>= b) == !(a< b); }
For what it's worth, e.g. NaN's are an exception to that rule...
It's not an exception. The axiom only applies to LessThanComparable types. Technically, double isn't LessThanComparable, because it violates this rule.
Given that double is a commonly used type (and the fact that it has an order is also often important), this does suggest that we may not want to always guarantee that these consistency conditions hold, or may want to allow certain values such as NaN to not satisfy the consistency conditions while still allowing using the of type.
On Sat, May 28, 2011 at 4:16 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
On 05/28/2011 12:42 PM, Pyry Jahkola wrote:
On 2011-05-28 21:59:57 +0300, Matt Calabrese said:
On Sat, May 28, 2011 at 2:55 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
I don't have the concepts proposal handy, but doesn't LessThanComparable have an axiom that requires that (a < b) is equivalent to (b > a)?
Yes.
axiom Consistency(T a, T b) { (a > b) == (b < a); (a <= b) == !(b < a); (a >= b) == !(a < b); }
For what it's worth, e.g. NaN's are an exception to that rule...
It's not an exception. The axiom only applies to LessThanComparable types. Technically, double isn't LessThanComparable, because it violates this rule.
Sorry, this is sort of on a tangent, but this is, imo, one of the problems with what would have been 0x concepts. According to N2914, LessThanComparable is an auto concept, meaning that as long as a type has an operation that matches the pseudo-signature bool operator< ( T const&, T const& ), then that type is LessThanComparable, even though the compiler can't really "check" the axioms. So in hypothetical 0x concept-land, checking if double models LessThanComparable would yield true. Most auto concepts that have axioms are scary. -- -Matt Calabrese
AMDG On 05/28/2011 02:00 PM, Matt Calabrese wrote:
On Sat, May 28, 2011 at 4:16 PM, Steven Watanabe <watanabesj@gmail.com>wrote: Sorry, this is sort of on a tangent, but this is, imo, one of the problems with what would have been 0x concepts. According to N2914, LessThanComparable is an auto concept, meaning that as long as a type has an operation that matches the pseudo-signature bool operator< ( T const&, T const& ), then that type is LessThanComparable, even though the compiler can't really "check" the axioms. So in hypothetical 0x concept-land, checking if double models LessThanComparable would yield true.
That's usually what we want, because double is close enough to being LessThanComparable as long as you avoid NaNs.
Most auto concepts that have axioms are scary.
In Christ, Steven Watanabe
participants (5)
-
Jeremy Maitin-Shepard -
Matt Calabrese -
Pyry Jahkola -
Steven Watanabe -
Vicente Botet