[result_of] Regression: compilation errors on C++03 compilers when defining BOOST_RESULT_OF_USE_DECLTYPE
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? Regards, Michel
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. 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. But I can also see how this could cause trouble. Thoughts? -- Eric Niebler BoostPro Computing http://www.boostpro.com
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.
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). Regards, Michel
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
On 25/04/12 15:28, 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.
Why would you ask result_of to use decltype when you don't have it?
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.
Why would you ask result_of to use decltype when you don't have it?
+1 Defining BOOST_RESULT_OF_USE_DECLTYPE when your compiler doesn't support decltype seems like a logic error to me. I would rather be alerted to logic errors than have an explicit instruction (defining BOOST_RESULT_OF_USE_DECLTYPE) be ignored to work around them. Regards, Nate
Le 25/04/12 00:14, Michel Morin a écrit :
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.
How do you expect boost::result_of behave in this case? I will be surprised if when requesting it to use decltype, boost::result_of used instead any workaround. The best think the library could do is to report an explicit error and/or provide a BOOST_RESULT_OF_USE_DECLTYPE_IF_AVAILABLE which could behave as you are requesting. Just my 2cts, Vicente
participants (5)
-
Eric Niebler -
Mathias Gaunard -
Michel Morin -
Nathan Ridge -
Vicente J. Botet Escriba