From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2008-06-24 12:51:10
On Tue, Jun 24, 2008 at 12:12 PM, Mathias Gaunard
> Steven Watanabe wrote:
>> Can't you use result_of?
> As far as I can see, the current boost::result_of implementation doesn't
> use decltype or typeof.
The boost::result_of on svn trunk uses decltype when
BOOST_HAS_DECLTYPE is defined. This happens automatically for gcc
versions after 4.2.
> I suppose implementing decltype on top of typeof is not a big problem
> (you only need to check whether the expression is a reference or not)
> however both have problems with mangling when used in a return type, at
> least in GCC.
> That basically means you can't always rely on them working. I thought
> decltype didn't have those mangling problems, looks like it is a regression.
> As for the correct way to do that, I suppose it should be possible to
> tell boost::result_type with a macro definition to use Boost.Typeof,
> which in turn can use either native or emulation.
This might not be a bad idea for compilers that lack decltype -
perhaps it could be offered as an alternative to the TR1 heuristic. Of
course, this would break compatibility with TR1 and C++0x in some
cases, which might cause more problems than it solves. But if the
various alternative result_of implementations are documented properly
(and perhaps placed in separate namespaces) then it shouldn't be so
> However range_ex only forwards algorithms and adaptors to Boost.Iterator
> and maybe the standard library. Maybe it's these that ought to use
> boost::result_of in the first place?
This is an excellent point. The standard library essentially relies on
concepts like SGI's AdaptableUnaryFunction, which requires expressions
of the form funtor::result_type, funtor::argument_type, etc. I think
it would be useful to have <functional> and <algorithm>
implementations that support an alternative concept framework
requiring expressions of the form result_of<functor(T)>::type and
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk