On Wed, May 28, 2008 at 6:51 PM, Sohail Somani <sohail@taggedtype.net> wrote:
Daniel Walker wrote:
On Wed, May 28, 2008 at 1:07 PM, Sohail Somani <sohail@taggedtype.net> wrote:
Hello,
Following up on several discussion over the last few weeks, I've placed an implementation of a polymorphic call wrapper (and associated utilities) similar to Boost.Function in the file polymorphic_function.zip in the Function Objects directory on vault at http://tinyurl.com/56zvo4. For those of us just joining, can you please give the main motivation for use of this new type? I hear polymorphic function and think many
Daniel Walker wrote: things, none of which may be close to the truth.
Thanks.
Sure. The short answer is that for an instance of boost::function, the return and argument types are fixed, whereas for an instance of polymorphic_function, they may vary. So, polymorphic_function allows you to deal with arbitrary callable object types without being forced to fix the return and argument types if one of those arbitrary callable objects happens to have a templated or overloaded operator().
Great explanation, thanks.
So barring the do_division example, does it solve an existing problem? I'm not saying it isn't useful, I'm just trying to figure out if there is a problem I have currently that I could use to solve this or whether there are a greater class of problems we can now solve easily because this class exists.
Good question. I suppose you could say that using polymorphic function objects interchangeably with builtin functions is currently problematic, because you loose any benefit of having a templated operator() as soon as you call wrap it in boost::function. But really, since you could never invoke call wrappers polymorphically before, I suppose this opens up a new class of problems that can now be addressed. Probably a better way to put it is that boost::function gives you one category of call wrapper, and polymorphic_function introduces a new category of call wrapper that supports a larger set of use cases. For example, "overriding" the compiler's argument deduction with functional_cast is a new use for call wrappers. functional_cast may be easier to use than the current boost::function::target member, but when combined with polymorphic_function it also introduces new use cases: Essentially, it allows you to restrict argument type deduction or change restrictions multiple times. (Really, you're changing the types used in argument forwarding.) In the example of my demo, polymorphic_function and functional_cast were used to defer type erasure and could be used to re-erase a function object multiple times with multiple call signatures, because polymorphic_function, unlike boost::function, doesn't force the user to erase the callable object at instantiation. I think these are all new use cases. Daniel Walker