Boost logo

Boost :

Subject: Re: [boost] [functional] [overloaded_function] polymorphic functions?
From: Gordon Woodhull (gordon_at_[hidden])
Date: 2012-03-14 16:50:45


Hi Lorenzo,

On Feb 18, 2012, at 6:24 AM, John Bytheway wrote:
> On 18/02/12 03:16, Lorenzo Caminiti wrote:
>> I spent some time trying to make overloaded_function support
>> polymorphic functions but I had little success :(

Thank you for attempting it! This is something that came up as a possible better solution in the Conversion review in August. (For which my report is grievously late but not forgotten.)

>>
>> 1) I was able to do this (see code below):
>>
>> overloaded_function<
>> void (int)
>> , functor<poly, void (generic)>
>>> o(f, p);
>> o(321);
>> o(3.21);
>> o("cba");
>>
>> But I don't like it because I explicitly have to pass the functor type
>> poly. I wanted instead to only use generic to tag the template
>> parameters in the signature:
>>
>> overloaded_function<
>> void (int)
>> , void (generic)
>>> o(f, p);
>> o(321);
>> o(3.21);
>> o("cba");
>>
>> I'd consider this acceptable but I wasn't able to program this because
>> I loose p's type (poly) in base so base cannot hold a reference to the
>> functor p... Is there a way around this? (Some type-erasure magic
>> maybe??)
>
> If the type of o did not involve poly, then you could pass a reference
> to o to another translation unit where the definition of poly was not
> visible. In that other translation unit you could call it with an
> arbitrary type, which would have to instantiate poly::operator() without
> sight of its definition. Therefore, I conclude that this is clearly
> impossible.

I had neglected the fact that overloaded_function does type erasure (duh). I guess this would only be possible if the polymorphic result_of (or equivalent) is passed to overloaded_function. Probably not worth it.

Sorry if I sent you on a wild goose chase! I really appreciate the effort, and knowing that this technique could be used as long as type erasure is not required (as it isn't for Conversion).

Cheers,
Gordon


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk