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

C++ 0x <забастовка> имеет имела предложение по функциям по умолчанию, таким образом, Вы могли сказать default 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, потому что операторы сравнения могут быть выведены для типов, для которых Вы не ожидаетесь.

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

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

можно также генерировать "+" от "+ =", - от "-=", и т.д.... (см. полный список здесь )

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

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

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

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

, Кроме того - они не занимают много времени писать, делают их?!

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

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

Так вместо, "почему C++ не имеет значения по умолчанию operator==()?", вопрос должен был быть, "почему C++ имеет присвоение по умолчанию и копирует конструктора?", с ответом, являющимся теми объектами, были включены неохотно Stroustrup для назад совместимости с C (вероятно, причина большинства бородавок C++, но также и вероятно основная причина популярности C++).

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

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

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