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

Конечно, деструктор предоставляется бесплатно.

В одном из своих недавних выступлений Алекс Степанов указал, что было ошибкой не иметь автоматического назначения по умолчанию ==, точно так же, как есть автоматическое назначение по умолчанию (=) при определенных условиях. (Аргумент об указателях непоследователен, потому что логика применима как к =, так и к ==, а не только ко второму).

@becko, это одна из первых в серии «Эффективное программирование с компонентами» или «Программирование разговоров» на A9, доступных на Youtube.

См. Этот ответ для информации о C++ 20: stackoverflow.com/a/50345359

Эта проблема не мешает ему генерировать копию ctor, где это довольно вредно.

Конструкторы копирования используются в совершенно другом контексте, чем операторы сравнения. И, IMHO, его контекст понятен в том, что он делает.

Существует проблема совместимости с C: C89 создает код для структур, который имитирует присваивание C++ (и, возможно, конструкторы копирования ... я должен проверить). Таким образом, обычно C++ генерирует похожие коды.

Конструкторы копирования (и operator=) обычно работают в том же контексте, что и операторы сравнения, то есть ожидается, что после выполнения a = ba == b верен. Компилятору определенно имеет смысл предоставить operator== по умолчанию, используя ту же семантику агрегированного значения, что и для operator=. Я подозреваю, что paercebal действительно прав в том, что operator= (и copy ctor) предоставляются исключительно для совместимости с C, и они не хотели ухудшать ситуацию.

-1. Конечно, вам нужно глубокое сравнение, если бы программист хотел сравнение указателя, он бы написал (& f1 == & f2)

Виктор, предлагаю переосмыслить свой ответ. Если класс Foo содержит Bar *, то как компилятор узнает, хочет ли Foo :: operator == сравнить адрес Bar * или содержимое Bar?

@Mark: если он содержит указатель, сравнение значений указателя является разумным - если он содержит значение, сравнение значений разумно. В исключительных случаях программист может отменить. Это похоже на то, как в языке реализовано сравнение между целыми числами и указателями на целые числа.

-1, как указывалось другими, это непоследовательный аргумент по сравнению с operator =

Ни одна из указанных причин не является действительной. Если бы в стандарте C++ говорилось, что компиляторы должны предоставлять по умолчанию оператор ==, сравнивающий каждое значение поля, это было бы не самым безумным. И, черт возьми, если нам нужна защита от указателей, просто выдайте предупреждение или ошибку в таких случаях.

@MarkIngram: ваше замечание не имеет смысла. компилятор, реализованный оператором ==, должен просто вызывать операторы == для всех членов, если они доступны. так, например, clone_ptr не нарушит глубокую цепочку. и std :: vector тоже. однако указатели и интеллектуальные указатели будут сравниваться неглубоко.

Компилятору не нужно в этом разбираться. Один из двух вариантов может быть указан в качестве стандарта, тогда поставщики компилятора просто должны будут следовать этому стандарту. Очевидным выбором, конечно же, было бы неглубокое сравнение указателей и сравнение значений для членов, точно так, как описывает v.oddou.

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

@JollyRoger, не совсем, оператор присваивания может просто назначать каждую переменную-член, двусмысленности нет.

Я не понимаю, насколько сложно сравнивать ценность каждого члена по отдельности. Если бы пользователь хотел сравнить адреса каждого объекта, он бы реализовал &A == &B и четко об этом сообщил. Что касается глубоких сравнений, таких как strcmp, они не вызывают проблемы, потому что C++ довольно четко понимает, что указатели являются целочисленными значениями (адресами), которые можно нормально сравнивать (==) с другим указателем.

Это несоответствие сохраняется и в стандартном комитете. В C++ 20 они изменили свое мнение. Теперь вы можете запросить оператор сравнения по умолчанию (при условии строгого порядка).

Конструктор перемещения также может быть установлен по умолчанию, но я не думаю, что это относится к operator==. Какая жалость.

Для структур POD нет двусмысленности - они должны вести себя точно так же, как и любой другой тип POD, а именно равенство значений (а не ссылочное равенство). Один int, созданный посредством копирования ctor из другого, равен тому, из которого он был создан; единственное, что логично сделать для struct с двумя полями int, - это работать точно так же.

Хорошо, но что, если структура POD имеет значение, релевантность которого зависит от другого значения. В случае, если значение не имеет значения, побитовое равенство больше не выполняется. Равенство действительно может варьироваться от одного и того же объекта (только с указателями / ссылками) до чего-либо, что несколько экономит (возможно, подкласса)

Это правда, но в C++ есть четкое определение «значения» (это все, что копируется в конструкторе копирования по умолчанию). Равенство по умолчанию, если оно есть, определенно будет работать таким же образом: оно просто вызовет operator= для каждого поля. Это гарантирует, что любые значения POD сравниваются как значения, указатели сравниваются по ссылке, а объекты с переопределенными методами operator= сравниваются так, как задумано разработчиком класса. Я бы сказал, что концептуально является легко определить равенство. Они не сделали этого по другим причинам.

@PavelMinaev Даже для структур POD это зависит от того, что они представляют, и являются ли они одинаковыми. Следует ли определять равенство как идентичность, эквивалентность или другой вариант. Я согласен с вами, что для многих структур POD правильным ответом является эквивалентность (одинаковые значения данных).

@PavelMinaev: Все варианты использования универсальных средств тестирования эквивалентности, которые я могу придумать, требуют, чтобы каждый объект сравнивался эквивалентным самому себе. К сожалению, IEEE-754 запрещает операторам == и != проявлять такое поведение.

@mgiuca: Учитывая struct {double v;} a,b; a.v=0.0/0.0; b=a;, что должен сообщить a==b? Если бы не нарушенное поведение == с типами с плавающей запятой, тогда a.v==b.v был бы истинным, а a==b не представлял бы проблемы. Тем не менее, хотя я вижу большую ценность в наличии стандартных средств запроса объектов на проверку эквивалентности, такая полезность будет зависеть от договорного требования, согласно которому тест ведет себя как отношение эквивалентности, чего оператор == не может сделать. со всеми типами.

@supercat Почему вы считаете, что автоматический оператор == должен быть обязательным для удовлетворения рефлексивности? Я согласен, что это было бы идеально, но, учитывая, что в C++ уже есть операторы ==, которые не являются рефлексивными (как вы указываете), автоматически сгенерированный оператор == для составного типа может быть настолько хорош, насколько хорош операторы == его полей. Это не умаляет полезности автоматической генерации оператора == по умолчанию, который говорит, что «мы равны, если все наши поля равны согласно ==».

@mgiuca: Я вижу значительную полезность универсального отношения эквивалентности, которое позволило бы использовать любой тип, который ведет себя как значение, в качестве ключа в словаре или подобной коллекции. Однако такие коллекции не могут работать с пользой без отношения гарантированно-рефлексивной эквивалентности. IMHO, лучшим решением было бы определить новый оператор, который все встроенные типы могли бы разумно реализовать, и определить некоторые новые типы указателей, которые были похожи на существующие, за исключением того, что некоторые определяли бы равенство как ссылочную эквивалентность, в то время как другие связывались бы с целевым оператор эквивалентности.

@supercat: Это действительно просто аргумент для реализаций ==, чтобы они подчинялись правилам отношений эквивалентности. К сожалению, этот корабль уже отплыл, и я не думаю, что введение нового оператора, который почти точно такой же, как ==, за исключением нескольких угловых случаев, действительно так полезно. Насколько мне известно, встроенные типы все подчиняются законам эквивалентности, отличным от float и double. Конечно, определяемые пользователем типы могут определять == и нарушать эти законы, но они тоже могут это сделать с вашим новым оператором. Ничто из этого не влияет на то, полезно ли иметь автоматический == для пользовательских типов или нет.

@mgiuca: Есть много ситуаций, когда необходимо проверить эквивалентность чисел с плавающей запятой. Если программисты, желающие проверить эквивалентность fp, должны написать что-то вроде bool equals(double x, double y) { return (x==y) || (x!=x) && (y!=y); }, такое тестирование будет неэффективным даже на оборудовании, которое позволяет проводить прямое тестирование эквивалентности. Добавление средства проверки эквивалентности, которое будет работать для типов fp, но также может быть реализовано другими типами, которые обещают, что оно представляет отношение эквивалентности, казалось бы лучше, чем добавление одного только для типов fp.

@supercat Извините за медленный ответ. Да, я согласен с тем, что было бы полезно иметь надлежащий эквивалент для FP. Скорее, корень проблемы, о которой вы говорите, заключается не в том, что оператор == нарушен, а в том, что нарушено равенство для FP. == практически во всех смыслах и целях действительно представляет собой класс эквивалентности, и поэтому автоматическое расширение его до структур имеет смысл. У него просто есть один редкий крайний случай, когда он сломан. Добавление нового оператора только запутает ситуацию и практически не решит никаких проблем. («Почему есть 2 оператора равенства ?!»)

@supercat По аналогии, вы можете привести почти тот же аргумент для оператора +, поскольку он неассоциативен для чисел с плавающей запятой; то есть (x + y) + z! = x + (y + z) из-за способа округления FP. (Возможно, это гораздо более серьезная проблема, чем ==, потому что это верно для обычных числовых значений.) Вы можете предложить добавить новый оператор сложения, который работает для всех числовых типов (даже int) и почти такой же, как +, но он ассоциативный (как-то). Но тогда вы добавили бы в язык раздувания и путаницы, не помогая на самом деле такому количеству людей.

@mgiuca: Часто очень сильно полезно иметь вещи, которые очень похожи, за исключением крайних случаев, и ошибочные попытки избежать таких вещей приводят к ненужным сложностям. Если клиентскому коду иногда требуется, чтобы крайние случаи обрабатывались одним способом, а иногда - другим, наличие метода для каждого стиля обработки избавит клиента от большого количества кода обработки крайних случаев. Что касается вашей аналогии, нет способа определить операцию со значениями с плавающей запятой фиксированного размера для получения транзитивных результатов во всех случаях (хотя некоторые языки 1980-х годов имели лучшую семантику ...

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

Есть причина, по которой rel_ops устарел в C++ 20: потому что это не работает, по крайней мере, не везде и, конечно, не всегда. Нет надежного способа заставить sort_decreasing() скомпилировать. С другой стороны, Boost.Operators работает и всегда работал.

Хороший ответ. Я просто хотел бы отметить, что в C++ 11 вместо того, чтобы делать оператор присваивания и конструктор копирования частными, вы можете полностью удалить их следующим образом: Foo(const Foo&) = delete; // no copy constructor и Foo& Foo=(const Foo&) = delete; // no assignment operator

«Однако C++ унаследовал свои конструкторы присваивания и копирования по умолчанию от C». Это не означает, почему вы должны создавать ВСЕ типы C++ таким образом. Они должны были просто ограничить это простыми старыми POD, только типами, которые уже есть в C, не более.

Я, конечно, могу понять, почему C++ унаследовал это поведение от struct, но я действительно хочу, чтобы он позволял class вести себя по-другому (и разумно). В процессе это также дало бы более значимую разницу между struct и class, помимо доступа по умолчанию.

C++ не использует memcpy для operator= - это будет работать только для типов POD, но C++ предоставляет operator= по умолчанию и для типов, отличных от POD.

Да, C++ реализовал = более изощренным способом. Кажется, C просто реализовал = с простым memcpy.

@ dcmm88 К сожалению, он не будет доступен в C++ 17. Я обновил ответ.

Однако модифицированное предложение, которое допускает то же самое (кроме краткой формы), будет в C++ 20 :)

@artin Это имеет смысл, поскольку добавление новых функций в язык не должно нарушать существующую реализацию. Добавление новых стандартов библиотеки или новых возможностей компилятора - это одно. Добавление новых функций-членов туда, где их раньше не было, - это совсем другая история. Чтобы обезопасить свой проект от ошибок, потребуется гораздо больше усилий. Я лично предпочел бы, чтобы флаг компилятора переключался между явным и неявным значением по умолчанию. Вы строите проект из более старого стандарта C++, используйте явное значение по умолчанию по флагу компилятора. Вы уже обновили компилятор, поэтому вам следует правильно его настроить. Для новых проектов сделайте это неявным.

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

Я удивлен, что они использовали Point в качестве примера для операции заказ, поскольку не существует разумного способа по умолчанию упорядочить две точки с координатами x и y ...

@pipe Если вам все равно, в каком порядке расположены элементы, имеет смысл использовать оператор по умолчанию. Например, вы можете использовать std::set, чтобы убедиться, что все точки уникальны, а std::set использует только operator<.

О типе возврата auto: для этот случай всегда можно предположить, что это будет std::strong_ordering от #include <compare>?

@kevinarpe Тип возврата - std::common_comparison_category_t, который для этого класса становится порядком по умолчанию (std::strong_ordering).