2

Что такое правильный/канонический способ перегрузки двоичных реляционных операторов в C++?Правильный способ перегрузки двоичных реляционных операторов в C++

ли лучше использовать функции члена или friend свободные функции?

т.д .:

class X { 
public: 
    ... 

    // Use member function overloads 
    bool operator==(const X& rhs) const { 
    return m_text == rhs.m_text; 
    } 

private: 
    std::string m_text; 
}; 

или:

class X { 
public: 
    ... 

    // Use friend free function overloads 
    friend bool operator==(const X& lhs, const X& rhs) { 
    return lhs.m_text == rhs.m_text; 
    } 

private: 
    std::string m_text; 
}; 
+0

[Этот вопрос] (http://stackoverflow.com/questions/1691007/whats-the-right-way-to-overload-operator-for-a-class-hierarchy?rq=1), возможно, может помочь. – Rakete1111

ответ

3

Единственное, что вы должны знать о неявные преобразования.

Если ваш класс поддерживает неявные преобразования из других типов, может оказаться полезным сделать оператор == другом для поддержки неявных преобразований по его первым аргументам.

В других случаях я полагаю, что это скорее вопрос стиля.

+0

Исправьте меня, если я ошибаюсь, но неявные преобразования происходят даже с операторами-членами. –

+1

@BrunoFerreira в основном, параметры имеют право на неявные преобразования, только если они перечислены в списке параметров, но когда * operator == * является функцией-членом, первым параметром является * this *, и он не имеет права на неявное преобразование. –

+0

Несомненно. [Я сделал небольшой тестовый пример] (http://coliru.stacked-crooked.com/a/5eefd0778684b48e) и да, если я удалю неявное преобразование в int, это не сработает. –

3

Это не имеет большого значения, за исключением того, что

  • экземпляр X должен быть на левой руке на стороне оператора равенства для версии членов работать. Если вы когда-нибудь захотите написать

    X x("hello"); 
    string s("hello"); 
    assert(s == x); 
    

    вам не нужен член.

  • Если вы реализуете все двоичные реляционные операторы, это потенциально большое увеличение площади вашего класса.

    Как правило, я предпочитаю, чтобы этот вспомогательный интерфейс оставался отдельно от логики основного класса, если это возможно (если, конечно, основной проблемой вашего класса является сравнение).

    Использование операторов, не являющихся друзьями, и минимальный публичный интерфейс, возможно, даже лучше.