Re: [boost] [type_erasure] default implementation of concept signatures

Subject: Re: [boost] [type_erasure] default implementation of concept signatures
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2011-05-28 14:55:59

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