Question

Using Visual Studio 2010 SP1:

#include <vector>

//namespace XXX {
  struct Test
  {
    bool operator==(const Test& r) const  { return true; }
  };
//}
//typedef XXX::Test Test;

template <typename T> inline bool operator!=(const T& l,const T& r) 
{ return !(l==r); }

int main()
{
  std::vector<Test> vt;
  std::vector<Test> vt2 = std::move(vt);
  return 0;
}

If I compile the code above as is, it fails with this error:

1>C:\apps\MVS10\VC\include\vector(609): error C2593: 'operator !=' is ambiguous
1>          C:\apps\MVS10\VC\include\xmemory(268): could be 'bool std::operator !=<_Ty,_Ty>(const std::allocator<_Ty> &,const std::allocator<_Ty> &) throw()'
1>          with
1>          [
1>              _Ty=Test
1>          ]
1>          test.cpp(11): or       'bool operator !=<std::allocator<_Ty>>(const T &,const T &)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _Ty=Test,
1>              T=std::allocator<Test>
1>          ]
1>          while trying to match the argument list '(std::allocator<_Ty>, std::allocator<_Ty>)'
1>          with
1>          [
1>              _Ty=Test
1>          ]
1>          C:\apps\MVS10\VC\include\vector(606) : while compiling class template member function 'void std::vector<_Ty>::_Assign_rv(std::vector<_Ty> &&)'
1>          with
1>          [
1>              _Ty=Test
1>          ]

… where vector(609) resolves to this line:

        else if (get_allocator() != _Right.get_allocator())

OTOH, if I uncomment the namespace XXX-related lines, it compiles without complaint.

I have to think this is a compiler bug but I’m looking for some independent verification.

EDIT: Just by way of explanation, I came across this situation when recompiling some old code with VS2010 for the first time. The global operator was some cruft from years past (now removed). I just couldn’t understand why some code failed and others didn’t. The code above is my distillation of the failed case (obviously, old code would not contain calls to std::move()).

UPDATE: I logged a bug with MS and they responded that this has been fixed “in the next release of the compiler” – which I presume means Visual C++ 11. See: http://connect.microsoft.com/VisualStudio/feedback/details/731692/regression-involving-global-operator-and-std-vector

Answer 1

It’s a bug.

You’ve decided to provide operator!= for all types ever which is obviously going to cause conflicts with types which already have such an operator defined.

Argument Dependent Lookup during the resolution of a call to operator!= between two std::allocator<Test>s inside your library implementation ^[1] allows the namespace of Test to be searched (as well as std) when trying to find the operator!= to use ^[2].

So:

• in your broken case, that namespace is the global namespace, which also contains a operator!= that matches. Now, this shouldn’t matter, because the function in namespace std is a better match ^[3]; the VS bug is that an ambiguity is raised instead.

• but when Test is instead in namespace XXX (despite the typedef), the namespace searched due to the above rule is instead the namespace XXX, which contains no conflicting definition for operator!=.

Best not define operators for all types ever like that, in any case.

---

[1] ^{Some part of the implementation for your line std::vector<Test> vt2 = std::move(vt); on your compiler/library impl is invoking bool operator!=<std::allocator<Test>>(const std::allocator<Test>&, const std::allocator<Test>&).}

[2] ^{Citations follow:}

^{[C++11: 3.4.2/1]: When the postfix-expression in a function call (5.2.2) is an unqualified-id, other namespaces not considered during the usual unqualified lookup (3.4.1) may be searched, and in those namespaces, namespace-scope friend function declarations (11.3) not otherwise visible may be found. These modifications to the search
depend on the types of the arguments (and for template template arguments, the namespace of the template argument).}

^{[C++11: 3.4.2/2]: For each argument type T in the function call, there is a set of zero or more associated namespaces and a set of zero or more associated classes to be considered. The sets of namespaces and classes is determined entirely by the types of the function arguments (and the namespace of any template template argument). Typedef names and using-declarations used to specify the types do not contribute to this set. The sets of namespaces and classes are determined in the following way:}

• ^[..]
• ^{If T is a class type (including unions), its associated classes are: the class itself; the class of which it is a member, if any; and its direct and indirect base classes. Its associated namespaces are the namespaces of which its associated classes are members. Furthermore, if T is a class template specialization, its associated namespaces and classes also include: the namespaces and classes associated with the types of the template arguments provided for template type parameters (excluding template template parameters); the namespaces of which any template template arguments are members; and the classes of which any member templates used as template template arguments are members. [ Note: Non-type template arguments do not contribute to the set of associated namespaces. —end note ]}
• ^[..]

[3] ^{Citations follow:}

^{[C++11: 13.3.3/1]: Given these definitions, a viable function F1 is defined to be a better function than another viable function F2 if for all arguments i, ICSi(F1) is not a worse conversion sequence than ICSi(F2), and then:}

• ^[..]
• ^{F1 and F2 are function template specializations, and the function template for F1 is more specialized than the template for F2 according to the partial ordering rules described in 14.5.6.2.}

^{[C++11: 14.5.6.2/2]: Partial ordering selects which of two function templates is more specialized than the other by transforming each template in turn (see next paragraph) and performing template argument deduction using the function type. The deduction process determines whether one of the templates is more specialized than the other. If so, the more specialized template is the one chosen by the partial ordering process.}

^{My interpretation is that this process determines that the function in std is “more specialised” than the one in the global namespace, so there in fact should not be an ambiguity.}

---

_{Thanks @BoPersson and @DavidRodríguez for your valuable contributions to this kick-ass answer.}