Subject: Re: [boost] [type_erasure] default implementation of concept signatures
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2011-05-28 14:55:59
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<(),
>>> 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
>> 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
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk