История вопроса
До C++20 разработчики вручную реализовывали шесть операторов сравнения для сортируемых типов. Этот шаблон часто вводил тонкие логические несоответствия между отношениями равенства и порядка. Космический оператор был введен для консолидации этих операторов в одну каноническую операцию.
Проблема
Хотя оператор<=> снижает синтаксическую нагрузку, компилятор полагается на его тип возвращаемого значения для синтеза обратных выражений, таких как b < a из a > b. Не зная, является ли порядок строгим, слабым или частичным, компилятор не может безопасно генерировать эти преобразования.
Решение
Тип возвращаемого значения должен быть std::strong_ordering, std::weak_ordering или std::partial_ordering (или неявно преобразуемым). Эта стандартная категория позволяет компилятору генерировать обратные кандидаты и неявные проверки на равенство. Возврат auto или пользовательских типов отключает этот синтез, требуя ручной асимметрии перегрузки.
struct Widget { int id; // Правильно: позволяет генерировать обратные кандидаты std::strong_ordering operator<=>(const Widget&) const = default; };
Сценарий и проблема
Разработка SpatialIndex для GPU-ускоренной геометрии потребовала создания структуры BoundingBox со строгим слабым порядком для вставки в std::set. Ящики должны были сравниваться с сырыми массивами координат для пространственных запросов.
Решение 1: Ручная перегрузка операторов
Реализация двенадцати перегрузок (шести для BoundingBox, шести для массивов координат) обеспечивала явный контроль. Однако многословность создавала риск ошибок копирования между оператором< и оператором>, а поддержание согласованности во время рефакторинга оказалось утомительным.
Решение 2: Установленный космический оператор, возвращающий std::weak_ordering
Это автоматически генерировало все реляционные операторы из единого определения. Явный тип возвращаемого значения позволил компилятору обрабатывать обратные сравнения с массивами координат. Реализация гарантировала безопасность при исключениях и математическую согласованность без шаблонного кода.
Решение 3: Возврат auto
Использование auto operator<=>(const BoundingBox&) const = default предотвращало синтез обратных кандидатов. Сравнение сырого массива слева с BoundingBox справа не компилировалось. Эта асимметрия нарушала интерфейс пространственного запроса.
Решение и результат
Мы выбрали Решение 2 с std::weak_ordering, потому что ограничивающие ящики имеют эквивалентность (пересекающиеся ящики сравниваются как равные), но не математическое равенство. Это обеспечило бесшовную интеграцию со стандартными алгоритмами при поддержке гетерогенных сравнений координат.
Почему компилятор синтезирует оператор== из оператора<=>, и когда это не оптимально?
Компилятор генерирует оператор== как ((*this <=> other) == 0). Это обеспечивает согласованность, но заставляет выполнять полное сравнение по элементам, даже при проверке равенства. Явное указание оператора== позволяет производить оценку с коротким замыканием, возвращая false сразу после первого различия.
Как определение оператора<=> как члена, а не как скрытого друга нарушает симметрию?
Член оператор<=> позволяет неявные преобразования только на правом операнде во время разрешения перегрузки. Эта асимметрия предотвращает компиляцию выражений вроде double == MyClass, даже если MyClass может быть сконструирован из double. Использование скрытого друга позволяет использовать зависимый от аргумента поиск (ADL), позволяя обоим операндам неявно преобразовываться.
Чем std::compare_three_way отличается от ручного сравнения указателей?
std::compare_three_way предоставляет полный порядок для указателей, который является согласованным по всему адресу, включая std::nullptr_t. Ручные сравнения указателей с использованием реляционных операторов вызывают неопределенное поведение при сравнении не связанных объектов. Использование стандартного функционального объекта обеспечивает портативную, четко определенную семантику для сортировки указателей.