|
Boost : |
From: Stjepan Rajko (stipe_at_[hidden])
Date: 2007-12-11 22:12:25
On Dec 9, 2007 2:54 AM, Tobias Schwinger <tschwinger_at_[hidden]> 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):
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk