Re: [boost] For inclusion to boost::function

From: Douglas Gregor (dgregor_at_[hidden])
Date: 2007-10-23 09:54:25

Preston A. Elder wrote:
> [snip example]
>
> The obvious problem with the latter is that it needs to be downcast
> implicitly, and some kind of exception thrown if the wrong type is passed.
>   
This doesn't seem like the kind of thing you would want to do 
implicitly. Rather, the user should request this 
try-to-downcast-and-throw-if-it-fails behavior.
> My solution is this:
> http://www.neuromancy.net/fisheye/browse/mantra/trunk/Mantra-I/mantra/utils/mem_fn_proxy_template.h?r=403
>
> Which is included by a boost preprocessor iteration here:
> http://www.neuromancy.net/fisheye/browse/mantra/trunk/Mantra-I/mantra/utils/mem_fn_proxy.h?r=403
>   
> As I mention, I use a lot of boost::function's own tricks.  I think this
> would be a lot cleaner if done as part of boost::function, rather than me
> re-implementing the same macros and such.
>   
Interesting. It's unfortunate that you have to jump through so many 
syntactic hoops to make this kind of code work. I will use this 
opportunity to point out how trivial this kind of thing will be to write 
once we have variadic templates :)
> I have made sure my implementation works, and more importantly, has all
> the tests you would expect (ie. that the return value arguments except the
> class are the same, that the class is derived from the original function
> typedef's first argument, and so on).
>
> Here is my test case:
> http://www.neuromancy.net/fisheye/browse/mantra/trunk/Mantra-I/test/scheduler/hello_world_task.cpp?r=403
>
> Any way, feedback is as always appreciated, but if someone could look at
> this for an addition to boost::function it would really be great 
>   
I don't think it belongs in boost::function per se, because 
boost::function has a very narrow focus on bridging to arbitrary 
function objects. It doesn't do any kind of adaptation of arguments, 
because bind already doesn't that. It's more in line with mem_fn, which 
handles the adaptation of a member pointer to make it a proper function 
object. The name "mem_fn_proxy" is a little weak, in that it doesn't 
really state the important behavior: downcasting "this". For this 
functionality, I, personally, have called it "mem_fn_downcast" and given 
it the same interface and semantics as mem_fn, except with the addition 
of the automatic downcasting behavior. Then, it would be up to Peter to 
decide whether he wants to add this variant to the bind/mem_fn library.

    - Doug