Inconsistent tidying behavior or uniformity between MSVC and Clang

I have the following code that I am compiling on Visual Studio 2013 and Clang:

#include <memory>

template<typename T>
class foo
{
public:
   typedef void (T::*CallbackFn)();

   foo(T* mem, CallbackFn cb) : m_member(mem), m_cb(cb) {}

private:
   T* m_member;
   CallbackFn m_cb;
};

class another
{
private:
   void callback() {}

public:
   std::unique_ptr<foo<another>> f{new foo<another>(this, &another::callback)};
};

int main() {}

      

( Live example here on Coliru )

When compiled on clang and GCC, this code works fine. However, on VS2013, it fails with:

main.cpp(22): error C2276: '&' : illegal operation on bound member function expression
main.cpp(22): error C2664: 'foo<another>::foo(const foo<another> &)' : cannot convert argument 1 from 'another *const ' to 'const foo<another> &'
          Reason: cannot convert from 'another *const ' to 'const foo<another>'
          No constructor could take the source type, or constructor overload resolution was ambiguous

      

For some reason, the VS compiler tries to call the copy constructor foo

, which doesn't make any sense. It completely ignores the second parameter to the constructor.

I wonder if I changed the constructor call foo

to curly braces like this:

std::unique_ptr<foo<another>> f{new foo<another>{this, &another::callback}};

      

It works great on MSVC. Can anyone explain this behavior? Is one way more correct than the other? Is this another MSVC bug or is it due to some unsupported C ++ 11 feature?

+3


source to share


1 answer


Can anyone explain this behavior?

After the compiler encounters the first error, the rest is just junk. Ignore it. (I usually only look at the first compiler error, see here for VC ++)



Is one way more correct than the other?

Both options are completely equivalent in this context. MSVC just doesn't parse &another::callback

and then ignores it to parse the string further.

+1


source







All Articles