On 4/25/2012 6:28 AM, Michel Morin wrote:
Eric Niebler wrote:
On 4/24/2012 3:14 PM, Michel Morin wrote:
If we define BOOST_RESULT_OF_USE_DECLTYPE, boost::result_of tries to use decltype-based implementation even on C++03 compilers. This causes compilation errors and it is a regression on C++03 compilers.
Is it intentional change?
I did intend this change.
I think this breaks too much code. Every code that (directly or indirectly) includes boost::result_of with `#define BOOST_RESULT_OF_USE_DECLTYPE` breaks in C++03.
True.
My thinking was: if Boost.Config is out of date or wrong about the presence of decltype for a particular tool chain, there should be a way for users to override it.
This should be the work of Boost.Config. Indeed, Boost.Config has several options to deal with this kind of situations. For example, we can use the following approach:
1. Prepare a user-supplied header for the compiler (say, new_clang),
// .../new_clang.hpp #include <boost/config/compiler/clang.hpp> #undef BOOST_NO_DECLTYPE
2. Compile with `-DBOOST_COMPILER_CONFIG=".../new_clang.hpp"`.
This approach does not need to modify the Boost.Config's code or the user code at all (other than preparing a user-supplied header).
OK. Since users have a way to override Boost.Config when it's wrong, I agree result_of should trust what Boost.Config tells it. I've reverted the behavior on trunk. Thanks. -- Eric Niebler BoostPro Computing http://www.boostpro.com