某种类型的 operator< 可以在编译单元之间有不同的定义吗？

Question

I wanted to create a std::set<X> , for a pod struct, X . I tried providing a free operator< . I did not want this operator to have a global effect (outside this compilation unit), so I set the operator< as static . ( link to code )

struct X { int value; };

static bool operator< (const X& a, const X& b) { return a.value < b.value; }

void foo() {
    std::set<X> some_set;
    some_set.insert({1});
}

This compiles fine.

However, if I move the operator< in an unnamed namespace ( link to code )

struct X { int value; };
namespace {
     bool operator< (const X& a, const X& b) { return a.value < b.value; }
}

void foo() {
    std::set<X> some_set;
    some_set.insert({1});
}

which should be equivalent,

then std::less<X> complains:

usr/local/include/c++/12.1.0/bits/stl_function.h:408:20: error: no match for 'operator<' (operand types are 'const X' and 'const X')
         { return __x < __y; }

Okay, I could have used a custom comparator instead.

But can anybody explain why the above does not work? In general, is it possible to provide a different operator implementation in compilation units of the same struct?

Answer 1

This boils down to following:

#include <iostream>

struct A {};

namespace
{
    void foo(A) {} // Your `operator<`.
}

namespace N
{
    void foo(int) {} // Some random `operator<` in `std`.

    template <typename T>
    void bar(T value)
    {
        foo(value);
    }
}

int main()
{
    N::bar(A{});
}

This doesn't work because N::foo shadows foo(A) in the unnamed namespace.

If there was no unnamed namespace, foo(A) would instead be found via ADL , because it would be in the same namespace as A .

---

Also note that this appears to violate one-definition rule. While your operator< is static , std::less is not, and its instantiations in different translation units will pick different operator< s, which appears to be illegal.

This could cause one of our operator< s to be used in every TU, when inline implementations of std::less from different TUs are ultimately merged by the linker.