Re: [boost] [result_of] Regression: compilation errors on C++03 compilers when defining BOOST_RESULT_OF_USE_DECLTYPE

Subject: Re: [boost] [result_of] Regression: compilation errors on C++03 compilers when defining BOOST_RESULT_OF_USE_DECLTYPE
From: Eric Niebler (eric_at_[hidden])
Date: 2012-04-25 13:45:44

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