Is this a VC++2010 compiler bug?

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

Maddiemadding

Have you tried this with a different compiler? – Stun

@GregHewgill: I cannot reproduce with GCC. – Maddiemadding

@GregHewgill: I lied in my previous comment, I don't have another compiler handy that supports C++11, so the answer is no. – Maddiemadding

@LightnessRacesinOrbit: about what? – Maddiemadding

@LightnessRacesinOrbit: 'misspoke' is more accurate. Compiling my original test case (which amounted to vt=f()) on an older GCC did work, but obviously that is not precisely equivalent to a version that supports rvalue-refs. I only later distilled it down to std::move(). – Maddiemadding

@mcmcc: Ah! Then I'll let you off. – Gardol

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.}

Gardol

The error says that the global != specialised for Test was found due to ADL. What's questionable is how line 606 even contains any operands from the global namespace, I guess. – Aileneaileron

@KerrekSB: Yes, which makes sense. That's one of the above-mentioned "conflicts". – Gardol

I should add, I've tried all combinations of typedefs, operator overloads, using namespace..., std::rel_ops, etc. to come up with other variations of this same error. This is the only way I could get it to fail (in this particular way). I'm having a hard time believing there isn't a compiler bug here somewhere. – Maddiemadding

@Maddiemadding : It appears to me that ADL is just doing its job here. While compiler bugs in VC++ are far from unheard of, I don't think this is one. – Kulp

The values compared are of type std::allocator<Test>. That would add the namespace of Test to the ADL search (in addition to std). – Reinaldo

@BoPersson: OK, and because the conflicting op!= is only in the same namespace as Test when Test is in the global namespace, that's the only time the conflicting op!= is injected into the candidate set..? – Gardol

@KerrekSB: how line 606 contains operands from the global namespace. Someone told me once ADL is a bitch... The reason that the global namespace is pulled for ADL is that Test resides there. Oh, but the elements being compared are not Test!, well, they are an specialization of a template with Test, and ADL will also bring into scope the namespaces of the associated template arguments. ADL is a bitch :) – Scheck

@DavidRodríguez-dribeas: A citation for that fact would greatly improve this answer :D – Gardol

@LightnessRacesinOrbit: ADL will bring into scope the namespaces of the arguments to the function, and the namespaces of the template arguments of the specializations in the case of templates, which is the reason why if Test is in the global namespace it gets picked. The other question, which might actually hint at a problem in the implementation, is why is the (also templated) op!= for the allocator not a better match than the fully generic one provided by the user. – Scheck

@LightnessRacesinOrbit: 3.4.2/2 [...]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) – Scheck

Strangely, it does compile fine on GCC. Is that compiler buggy then? – Aileneaileron

@DavidRodríguez-dribeas: Yeah, I suppose the next question is why this whole debacle results in ambiguity rather than selecting one of the matches. – Gardol

@KerrekSB: I think GCC is right and VS wrong. Considering that both templates were available in the same context (or get brought by ADL) the user defined template is a worse match than template <typename T> operator!=( allocator<T> const&, allocator<T> const& ). – Scheck

@KerrekSB: Could just be a result of the library implementation being slightly different. – Gardol

@DavidRodríguez-dribeas: Yes, that sounds right. The allocator requirements explicitly demand that you provide a free operator!=. – Aileneaileron

@DavidRodríguez-dribeas: But they're both user-defined templates. Or is there an "exemption" from user-definedness for library functions that I'm not aware of? – Gardol

@LightnessRacesinOrbit: No, it shouldn't. The error message is saying that it cannot decide among the two options, and I believe that applying the partial order defined in the standard the user defined one is less specialized than the one in the library, and thus the compiler should pick that one up. I am more and more convinced that there is a but in the implementation, it is just not on why it considers that template, but rather on why it considers it as good as the other. – Scheck

@LightnessRacesinOrbit: In my comments read user defined as defined by the user that wrote the question. Both are user defined types, but I did not want to have to say: the one defined by the person that wrote the question here and there. – Scheck

@DavidRodríguez-dribeas: I understand that we're now considering that a possible Best Viable Match bug is at play here, but I'm still not convinced I see it – Gardol

@DavidRodríguez-dribeas: OK, looking at the differing params to each op!= in the candidate set, I see where you're coming from. However, I refuse to attempt to decode 13.3.3. Please solve it for us then post the result as a comment, and then I'll steal it ;) – Gardol

@DavidRodríguez-dribeas: OK, I lied. I had a quick look through. I can't take this any further though as I'm stuck at 14.5.6.2/3 and how "more" or "less" specialisedness is really determined – Gardol

@LightnessRacesinOrbit a simple line of reasoning for the more/less specialized is: A is more specialized than B if all valid combinations of arguments to A are also valid arguments for B and there is at least one combination of arguments that is valid with B but not with A. ...foo(T*) is more specialized than ...foo(T) because all types that match the first template also match the second, and there are types that match the second (non pointers) that are not valid in the first. – Scheck

In this particular case, the allocator op!= can take only instantiations of allocator<> that are also valid arguments for the global op!=, but there are types (basically anything else) that are valid arguments for the global and not for the one in the library. – Scheck

@DavidRodríguez-dribeas: Sounds reasonable. I still haven't been able to come up with a citation for that, though. I simply reached the limit of my standard-fu. You may want to post your own answer, but if you don't, I'd really appreciate your writing an extra citation into footnote [3] if you figure it out =) – Gardol

Please ensure the relevant portions of this extended discussion is edited into the question and/or answer. – Goggler

@LasseV.Karlsen: IMO that's been done to my satisfaction thus far. I'm sure we'll clean up the comments when completely finished. – Gardol

Kudos to everyone that contributed to this answer. Very scholarly. – Maddiemadding