Re: [boost] RFC: type erasure

Subject: Re: [boost] RFC: type erasure
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-05-24 17:07:26

Steven Watanabe-4 wrote:
> 
> AMDG
> 
> On 05/23/2011 02:34 PM, Vicente Botet wrote:
>> 
>> I like how concepts are materialized using a template class that
>> implements
>> the default behavior of the concept and that can be specialized to map
>> type
>> to concepts. I understand that you need a second step to introduce the
>> functions themselves specializing concept_interface.
>> 
>> What I don't understand is the overloading issues. Could you use a
>> concrete
>> example to try to clarify the problems you have addressed?
>> 
> 
> Okay.  Problem 1: Name hiding for member functions.
> 
> typedef mpl::vector<
>     callable&lt;int(int)&gt;,
>     callable&lt;double(double)&gt;
>> test_concept;
> 
> If we just use the basic definition of
> concept_interface, the second overload
> will hide the first since the inheritance
> structure looks like:
> 
> struct callable1 {
>     int operator()(int);
> };
> 
> struct callable2 : callable1 {
>     double operator()(double);
> };
> 

I find this normal and expected behavior, so I don't see yet why do you need
to avoid this hiding.

I don't understand the use case of the example: when a using declaration
will be needed?

> For free functions, I had a problem akin to name
> hiding when I defined a single namespace scope
> overload with concept_interface arguments.  Using
> an inline friend function that takes the derived
> type works with some care to avoid duplicate
> definitions.
> 

I'm sorry but I don't reach to see what is the real problem. I guess it is
because I don't see the need of introducing the using sentence. Please could
you present a real concrete case of overloading free functions that needs
two different specializations of concept interface?

> You can check the tests for details on what I expect
> to work.  Most of the tests for specific concepts
> have a test_overload test case.
> 
> 

I've read some of them. I guess I understand what you expect to work, but I
don't see why you need to specialize twice the concept_interface class for
the same concept.

Best,
Vicente

--
View this message in context: http://boost.2283326.n4.nabble.com/RFC-type-erasure-tp3542886p3548241.html
Sent from the Boost - Dev mailing list archive at Nabble.com.