On Tue, Jun 24, 2008 at 12:12 PM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
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 bad.
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 argument_of<functor(T)>::type. Daniel Walker