Re: [Boost-users] [range] cannot use lambda predicate in adaptor with certain algorithms
Hi Daniel, Daniel Walker wrote:
At some point, BOOST_RESULT_OF_USE_DECLTYPE may be defined by default, probably when there's enough user interest, so thanks for cc'ing me. The reason it is currently not defined by default is that it is possible that it could introduce breaking changes to some C++03 function objects; e.g. if a function object defines result_type to be some type other than the type of a call expression, then in C++03 result_of would give the user-specified result_type rather than the actual result type, whereas in C++0x result_of always gives the actual result type. For example:
#include
#include struct f { typedef int result_type; double operator()(double); };
int main() { using namespace boost; typedef result_of
::type type; #ifdef BOOST_RESULT_OF_USE_DECLTYPE static_assert(is_same ::value, ""); #else static_assert(is_same ::value, ""); #endif }
Thank you for explaining the problem. And yes, backward compatibility is always problematic. IMO, this use case is not the intended use of boost::result_of, so is it reasonable to deprecate this? And how about adding a "Note" that warns this kind of codes will break in the future to the documentation? Regards, Michel P.S. Eric just completed a patch for BOOST_NO_DECLTYPE_N3276: http://permalink.gmane.org/gmane.comp.lib.boost.devel/219979
On Tue, May 31, 2011 at 9:37 PM, Michel MORIN
Daniel Walker wrote:
At some point, BOOST_RESULT_OF_USE_DECLTYPE may be defined by default, probably when there's enough user interest, so thanks for cc'ing me. The reason it is currently not defined by default is that it is possible that it could introduce breaking changes to some C++03 function objects; e.g. if a function object defines result_type to be some type other than the type of a call expression, then in C++03 result_of would give the user-specified result_type rather than the actual result type, whereas in C++0x result_of always gives the actual result type. For example:
#include
#include struct f { typedef int result_type; double operator()(double); };
int main() { using namespace boost; typedef result_of
::type type; #ifdef BOOST_RESULT_OF_USE_DECLTYPE static_assert(is_same ::value, ""); #else static_assert(is_same ::value, ""); #endif } Thank you for explaining the problem. And yes, backward compatibility is always problematic.
IMO, this use case is not the intended use of boost::result_of, so is it reasonable to deprecate this?
This is not an intended (or supported) use case at all. Nevertheless, it seemed reasonable to roll out decltype slowly.
And how about adding a "Note" that warns this kind of codes will break in the future to the documentation?
Sure. I added the following:
"In a future release, BOOST_RESULT_OF_USE_DECLTYPE may be enabled by
default on compilers that support decltype, so if you use the above
protocol please take care to ensure that the result_type and result<>
members are accurate. If you wish to continue to use the protocol on
compilers that support decltype, use boost::tr1_result_of, which is
also defined in
Daniel Walker wrote:
This is not an intended (or supported) use case at all. Nevertheless, it seemed reasonable to roll out decltype slowly.
OK, sounds good.
And how about adding a "Note" that warns this kind of codes will break in the future to the documentation?
Sure. I added the following:
"In a future release, BOOST_RESULT_OF_USE_DECLTYPE may be enabled by default on compilers that support decltype, so if you use the above protocol please take care to ensure that the result_type and result<> members are accurate. If you wish to continue to use the protocol on compilers that support decltype, use boost::tr1_result_of, which is also defined in
."
That's great, Daniel! Thank you for your quick work. Just a minor suggenstion: "the result_type and result<> members are accurate." --> "the result_type and result<> members accurately represent the result type." IMHO, the latter is more clear. Regards, Michel
participants (2)
-
Daniel Walker
-
Michel MORIN