On Dec 9, 2007 2:54 AM, Tobias Schwinger <tschwinger@isonews2.com> wrote:
Stjepan Rajko wrote:
Are there any arguments against implementing forward<F> using inheritance of (compressed_pair of) F?
If it ends up being never used we're adding unnecessary dependencies.
OK.
If someone presents me a convincing use case I'll add it. Maybe I'll add it anyway, but I'd feel much better about it if someone did...
I don't know about convincing, but I'll give it a shot. I suppose the general category of use cases would be "forwarders with benefits", i.e., something that builds on the forwarding functionality and provides something extra on top of it. Here is a quickly thrown together example of a class that inherits forward_adapter to allow both immediate forwarding, as well as delayed forwarding ("delayed forwarding" = you call once to provide the arguments, and then call again to execute a call to the underlying function object using the previously stored arguments): http://pastebin.com/mcc92c4f I haven't really used this in practice, so it might be a highly contrived example.
You mean like 'make_fused', etc...? No, I meant instead of ending up with a function object that does perfect forwarding, ending up with an actual function that does perfect forwarding. But the only way I can see of facilitating that would be factoring out the preprocessing code to make it easier for someone to implement one without code duplication.
So we're talking about an overloaded function (not a function pointer)?
Interesting. I doubt it's a good idea to promote duplication of 2**N overloads, except for very low N. Further, factoring our the preprocessing code seems like something I wouldn't want to do :-).
When I first wrote the review, I started writing something along the lines of "it might be useful to factor out the preprocessing code", thought about it a little, and promptly erased it :-) Cheers, Stjepan