Re: [boost] [Config] Big changes in C++0x detection...

Subject: Re: [boost] [Config] Big changes in C++0x detection...
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2011-03-16 18:39:25

On Wed, Mar 16, 2011 at 3:45 PM, Mathias Gaunard
<mathias.gaunard_at_[hidden]> wrote:
> On 16/03/2011 19:39, John Maddock wrote:
>>>>
>>>> * Remove the concept related macros.
>>>> * Tighten up most of the C++0x related tests, with the result that some
>>>> C++0x features that were previously enabled are no longer - this may
>>>> also cause the Boost.Config tests to fail on some platforms.
>>>> * Some C++0x features that were not previously enabled are now - because
>>>> they were passing the Boost.Config tests - there's at least one case
>>>> where this is causing regressions in other libraries - if any more pop
>>>> up please let me know ASAP!
>>>
>>> Any reason why decltype on MSVC10 is still not enabled?
>>
>> If someone tells me that this issue:
>> http://lists.boost.org/Archives/boost/2010/04/164645.php is fixed then
>> fine, otherwise it appears to be a lot trouble,
>
> I wasn't aware of this issue.
> But doesn't it only affect result_of, with decltype still usable in practice
> for other things?

result_of is little more than a synonym for decltype; e.g. for types F
and T, result_of<F(T)>::type evaluates to
decltype(declval<F>()(declval<T>())). The issue here is that msvc runs
out of heap space if decltype is used with a call expression in a
context in which the type of the call expression is incomplete.

https://connect.microsoft.com/VisualStudio/feedback/details/548883/c-use-of-decltype-causes-premature-template-instantiation

However, as far as I understand, this usage is not valid C++0x, since
a call expression is still required to have a complete type. So, I
don't believe this issue alone merits disabling decltype on msvc. In
the future, if the complete type requirement is removed from the
standard, then I expect Microsoft will try to comply. So, the question
is whether the current msvc decltype is close enough to the current
standard.

With regard to boost::result_of, users must explicitly enable the
decltype version by defining BOOST_RESULT_OF_USE_DECLTYPE, and either
way, the TR1 version is always available as boost::tr1_result_of,
which, I believe, Proto uses. So from the perspective of
boost::result_of, I see no reason to deny msvc users the option of
enabling decltype.

Daniel Walker