Почему компиляторы C ++ не определяют operator == и operator! =?

Я большой поклонник того, чтобы компилятор делал для вас как можно больше работы. При написании простого класса компилятор может дать вам «бесплатно» следующее:

• Конструктор по умолчанию (пустой)
• Конструктор копирования
• Деструктор
• Оператор присваивания ( operator=)

Но это не может дать вам никаких операторов сравнения - таких как operator==или operator!=. Например:

class foo
{
public:
    std::string str_;
    int n_;
};

foo f1;        // Works
foo f2(f1);    // Works
foo f3;
f3 = f2;       // Works

if (f3 == f2)  // Fails
{ }

if (f3 != f2)  // Fails
{ }

Есть ли для этого веская причина? Почему выполнение сравнения между членами будет проблемой? Очевидно, что если класс выделяет память, вам следует быть осторожным, но для простого класса наверняка компилятор может сделать это за вас?

Компилятор не знает, нужно ли вам сравнение указателей или глубокое (внутреннее) сравнение.

Безопаснее просто не реализовывать это и позволить программисту делать это самостоятельно. Тогда они могут сделать все предположения, которые им нравятся.

Аргумент, что если компилятор может предоставить конструктор копирования по умолчанию, он должен быть в состоянии обеспечить аналогичное значение по умолчанию, operator==()имеет определенный смысл. Я думаю, что причина решения не предоставлять сгенерированный компилятором по умолчанию для этого оператора может быть угадана из того, что сказал Страуструп о конструкторе копирования по умолчанию в «Проектировании и развитии C ++» (Раздел 11.4.1 - Управление копированием) :

Лично я сожалею, что операции копирования определены по умолчанию, и я запрещаю копирование объектов многих моих классов. Однако C ++ унаследовал свои конструкторы присваивания и копирования по умолчанию от C, и они часто используются.

Таким образом, вместо «почему в C ++ нет значения по умолчанию operator==()?», Вопрос должен был звучать так: «Почему в C ++ есть конструктор присваивания и копирования по умолчанию?», Ответ на который заключается в том, что эти элементы неохотно включались в Stroustrup для обратной совместимости с C (вероятно, причина большинства бородавок C ++, но также, вероятно, основная причина популярности C ++).

Для моих собственных целей в моей IDE сниппет, который я использую для новых классов, содержит объявления для частного оператора присваивания и конструктора копирования, так что при создании нового класса я не получаю операции присваивания и копирования по умолчанию - мне нужно явно удалить объявление из этих операций из private:раздела, если я хочу, чтобы компилятор мог генерировать их для меня.

Даже в C ++ 20 компилятор все равно не будет генерировать operator==для вас неявно

struct foo
{
    std::string str;
    int n;
};

assert(foo{"Anton", 1} == foo{"Anton", 1}); // ill-formed

Но вы получите возможность явного дефолта, == начиная с C ++ 20 :

struct foo
{
    std::string str;
    int n;

    // either member form
    bool operator==(foo const&) const = default;
    // ... or friend form
    friend bool operator==(foo const&, foo const&) = default;
};

Значение по умолчанию выполняется для каждого ==элемента ==(так же, как конструктор копирования по умолчанию выполняет создание элемента для каждого элемента). Новые правила также обеспечивают ожидаемые отношения между ==и !=. Например, с объявлением выше, я могу написать как:

assert(foo{"Anton", 1} == foo{"Anton", 1}); // ok!
assert(foo{"Anton", 1} != foo{"Anton", 2}); // ok!

Эта особенность (дефолт operator==и симметрия между ==и !=) происходит от одного предложения, которое было частью более широкой языковой функции operator<=>.

ИМХО, нет "веской" причины. Причина, по которой так много людей согласны с этим дизайнерским решением, заключается в том, что они не научились овладевать силой семантики, основанной на ценностях. Людям нужно написать много пользовательских конструкторов копирования, операторов сравнения и деструкторов, потому что они используют необработанные указатели в своей реализации.

При использовании соответствующих интеллектуальных указателей (например, std :: shared_ptr) конструктор копирования по умолчанию обычно в порядке, и очевидная реализация гипотетического оператора сравнения по умолчанию будет такой же.

Он ответил, что C ++ не сделал ==, потому что C не сделал, и вот почему C предоставляет только default =, но не == на первом месте. C хотел, чтобы все было просто: C реализовано = memcpy; однако == не может быть реализован memcmp из-за заполнения. Поскольку padding не инициализируется, memcmp говорит, что они разные, хотя они одинаковые. Та же проблема существует для пустого класса: memcmp говорит, что они разные, потому что размер пустых классов не равен нулю. Из вышесказанного видно, что реализация == более сложна, чем реализация = в C. Некоторые примеры кода, касающиеся этого. Ваша поправка приветствуется, если я ошибаюсь.

В этом видео Алексей Степанов, создатель STL, решает этот вопрос примерно в 13:00. Подводя итог, наблюдая за развитием C ++, он утверждает, что:

• К сожалению, == и! = Не объявляются неявно (и Бьярне соглашается с ним). В правильном языке эти вещи должны быть готовы для вас (он далее рекомендует, что вы не сможете определить ! = , Который нарушает семантику == )
• Причина, по которой дело обстоит так, имеет свои корни (как и многие проблемы C ++) в C. Там оператор присваивания неявно определяется с побитовым присваиванием, но это не сработает для == . Более подробное объяснение можно найти в этой статье Бьярна Страуструпа.
• В последующем вопросе « Почему тогда не использовалось сравнение членов по элементам», он говорит удивительную вещь : C был своего рода доморощенным языком, и парень, реализующий эти вещи для Ричи, сказал ему, что он считает, что это трудно реализовать!

Затем он говорит, что в (далеком) будущем == и ! = Будут сгенерированы неявно.

C ++ 20 позволяет легко реализовать оператор сравнения по умолчанию.

Пример из cppreference.com :

class Point {
    int x;
    int y;
public:
    auto operator<=>(const Point&) const = default;
    // ... non-comparison functions ...
};

// compiler implicitly declares operator== and all four relational operators work
Point pt1, pt2;
if (pt1 == pt2) { /*...*/ } // ok, calls implicit Point::operator==
std::set<Point> s; // ok
s.insert(pt1); // ok
if (pt1 <= pt2) { /*...*/ } // ok, makes only a single call to Point::operator<=>

Невозможно определить значение по умолчанию ==, но вы можете определить значение !=по умолчанию, с помощью ==которого вы обычно должны определять себя. Для этого вы должны сделать следующие вещи:

#include <utility>
using namespace std::rel_ops;
...

class FooClass
{
public:
  bool operator== (const FooClass& other) const {
  // ...
  }
};

Вы можете увидеть http://www.cplusplus.com/reference/std/utility/rel_ops/ для деталей.

Кроме того, если вы определите operator< , операторы для <=,>,> = могут быть выведены из него при использовании std::rel_ops.

Но вы должны быть осторожны при использовании, std::rel_opsпотому что операторы сравнения могут быть выведены для типов, для которых вы не ожидаете.

Более предпочтительным способом вывести связанный оператор из базового является использование boost :: operator .

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

Вы также можете генерировать «+» из «+ =», - из «- =» и т. Д. (См. Полный список здесь )

В C ++ 0x есть предложение функций по умолчанию, поэтому вы могли бы сказать, что default operator==; мы узнали, что это помогает сделать эти вещи явными.

Концептуально не легко определить равенство. Даже для данных POD можно утверждать, что даже если поля одинаковы, но это другой объект (по другому адресу), он не обязательно равен. Это на самом деле зависит от использования оператора. К сожалению, ваш компилятор не экстрасенс и не может вывести это.

Помимо этого, стандартные функции являются отличным способом выстрелить себе в ногу. Описанные вами значения по умолчанию в основном сохраняют совместимость со структурами POD. Однако они приводят к более чем достаточному хаосу, когда разработчики забывают о них или семантике реализаций по умолчанию.

Есть ли для этого веская причина? Почему выполнение сравнения между членами будет проблемой?

Это может не быть проблемой функционально, но с точки зрения производительности сравнение по элементам по умолчанию может оказаться более неоптимальным, чем назначение / копирование по умолчанию между членами. В отличие от порядка назначения, порядок сравнения влияет на производительность, потому что первый неравный элемент подразумевает, что остальные могут быть пропущены. Поэтому, если есть некоторые члены, которые обычно равны, вы хотите сравнить их последними, и компилятор не знает, какие члены с большей вероятностью будут равны.

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

class LocalWeatherRecord {
    std::string verboseDescription;
    std::tm date;
    bool operator==(const LocalWeatherRecord& other){
        return date==other.date
            && verboseDescription==other.verboseDescription;
    // The above makes a lot more sense than
     // return verboseDescription==other.verboseDescription
     //     && date==other.date;
    // because some verboseDescriptions are liable to be same/similar
    }
}

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

Просто чтобы ответы на этот вопрос оставались полными с течением времени: начиная с C ++ 20 он может быть автоматически сгенерирован командой auto operator<=>(const foo&) const = default;

Он сгенерирует все операторы: ==,! =, <, <=,> И> =, подробнее см. Https://en.cppreference.com/w/cpp/language/default_comparisons .

Из-за взгляда оператора <=>он называется оператором космического корабля. Также см. Зачем нам нужен оператор космического корабля <=> в C ++? ,

РЕДАКТИРОВАТЬ: также в C ++ 11 довольно аккуратная замена для этого доступна с std::tieсм. Https://en.cppreference.com/w/cpp/utility/tuple/tie для полного примера кода с bool operator<(…). Интересная часть, измененная для работы с ==:

#include <tuple>

struct S {
………
bool operator==(const S& rhs) const
    {
        // compares n to rhs.n,
        // then s to rhs.s,
        // then d to rhs.d
        return std::tie(n, s, d) == std::tie(rhs.n, rhs.s, rhs.d);
    }
};

std::tie работает со всеми операторами сравнения и полностью оптимизируется компилятором.

Я согласен, для классов типа POD компилятор может сделать это за вас. Однако то, что вы можете считать простым, компилятор может ошибаться. Так что лучше позволить программисту сделать это.

У меня был случай POD, когда два поля были уникальными, поэтому сравнение никогда не считалось бы верным. Однако сравнение, которое мне было нужно, сравнивалось только с полезной нагрузкой - то, что компилятор никогда не поймет или не сможет понять самостоятельно.

Кроме того - они не занимают много времени, чтобы написать, они ?!