On 4/9/2010 5:31 PM, Daniel Walker wrote:
The decltype result_of isn't on the 1.43 release branch. I believe Daniel James reverted the changes last night.
Yes. He also reverted a bunch of other fixes, which seems unfortunate to me. I can live with that, though.
So, as of right now, 1.43 won't ship with the decltype result_of, which is acceptable to me, but I still think we should leave the code on trunk for anyone who uses trunk.
I think on trunk we should start moving toward whatever solution we feel will be appropriate for 1.44.
fyi, gcc 5.0 does use decltype in it's headers.
You mean gcc-4.5? I see a tr1/functional header there that has an implementation of result_of that doesn't use decltype.
So, if we want Boost.TR1 to be TR1 on gcc 5.0 we may need to make a change or two. 5.0 was released 2 weeks ago.
If Boost.TR1 advertises itself as an implementation of TR1, then it should have an implementation of result_of that doesn't rely on decltype. (Waiting for John to jump in here.) That way, libraries like Proto that need the tr1 behavior (until decltype is fixed) can use std::tr1::result_of from boost/tr1/functional.hpp and forget about it. This should be possible in the 1.44 time frame and is a good long-term solution. In that world, boost::result_of could be free to use decltype or not as appropriate. But to be honest, I don't particularly like the fact that boost::result_of behaves differently depending on whether decltype is available or not -- it hurts code portability -- but utility/result_of is your baby now, and it's your call. -- Eric Niebler BoostPro Computing http://www.boostpro.com