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

Subject: Re: [boost] [Config] Big changes in C++0x detection...
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2011-03-18 07:56:02

On 18/03/2011 01:35, Stephan T. Lavavej wrote:
> [Eric Niebler]
>> Yes. So the behavior of vc10's decltype wrt this issue is in conformance with /current/
>> working paper -- which is broken, according to n3233. It will be discussed soon in Madrid.
>> If the proposed wording is accepted (and I hope to god it is), then VC10's decltype --along
>> with everybody else's-- will need to be fixed.
>> But please fix it anyway. :-)
>
> I'll ask the compiler team for a fix. I don't always get what I want, but the STL is the compiler's first and best customer, and I've been looking forward to making result_of 95% powered by decltype.
>
> (Keeping track of rvalue references v2, lambdas v1.1, rvalue references v2.1, rvalue references v3 - I actually don't know if that one was reverted in the Working Paper - and now decltype v1.1 can be exhausting!)

MSVC also has a lot of bugs with function types in general, which can 
affect result_of, function, or other similar things negatively.

Here is one bug:
https://connect.microsoft.com/VisualStudio/feedback/details/282942/syntax-error-on-valid-function-type-declarator

Here is a testcase of another bug that causes an error in result_of:

void foo(int) {}

struct bar_t
{
     template<typename Sig>
     struct result;

     template<typename This, typename F>
     struct result<This(F)>
     {
         typedef void type;
     };

     template<typename F>
     void operator()(const F&) const
     {
     }
};

template<typename F>
typename std::tr1::result_of<bar_t(const F&)>::type
bar(const F& f)
{
     bar_t b;
     return b(f);
}

void call_foo()
{
    bar(foo);
}

This fails with an error message in _Remove_reference called by _Result_of.

Changing it to bar(&foo) allows to work around the problem though.