From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2008-04-07 12:14:57
On Sat, Apr 5, 2008 at 9:15 PM, Eric Niebler <eric_at_[hidden]> wrote:
> Daniel Walker wrote:
> > Is this anything like what you're looking for?
> Yes, it works, it's hideously ugly and complicated, and nobody writes
> function objects like this in practice. It proves my point.
I agree that writing function objects that support argument dependent
return type deduction will be much more attractive with a result_of
implemented on top of decltype. The current result_of supports
automatic return type deduction for functions, function pointers, etc.
However, function objects are a special case, which requires the
author of the functor to advertise the return type either through
result_type or, for argument dependent functors, through result<>.
Now, with decltype this heuristic is no longer necessary and functors
can be handled fully automatically. Anything that requires manual
intervention is hideously ugly compared to that! ;-)
Also, surely the result<> convention is not That complicated. It's
been the standard practice (and in fact the only supported convention)
for argument dependent return type deduction with result_of for, um,
five years or more I believe. So, everybody who writes result_of
compatible functors with argument dependent return types has written
something like my example. It's been the only choice.
> > Note that there are specializations for result<> corresponding to
> > exactly the way the operator()s are overloaded, and the overloads use
> > result<> to specify they're return types. In a situation like this, I
> > find it easier to try to keep a specific one-to-one correspondence
> > between result<> specializations and overloads. It's a bit of a
> > manually convention, but as you both point out, without decltype
> > return type deduction can be tedious by nature.
> "It's a bit of a manual convention" is precisely my point. Not only is
> it manual and tedious, but it's a convention that (hardly) nobody else
> follows. In generic code, I can't rely on some arbitrary function object
> Foo to do anything reasonable when passed a reference wrapper.
Then I'm not sure that I see your motivation for using reference
wrappers in the first place. What exactly do you gain from it?
> The general issue is: given an unknown binary function object F, an
> object L which is known to be an lvalue, and an object R known to be an
> rvalue, how do I invoke F in C++0x? F(L,R) might do the wrong thing with
> the rvalue, and F(ref(L),R) might not compile.
> Only questions, no answers,
Well, I think you're making headway elsewhere in this thread. It looks
like you're getting closer to an answer!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk