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

Subject: Re: [boost] [type_erasure] default implementation of concept signatures
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-05-28 14:08:30

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-concept-signatures-tp3557724p3557837.html
Sent from the Boost - Dev mailing list archive at Nabble.com.