C++20 добавляет новый оператор, названный «космическим кораблем»: <=>. Не так давно Simon Brand опубликовал пост, в котором содержалась подробная концептуальная информация о том, чем является этот оператор и для каких целей используется. Главной задачей этого поста является изучение конкретных применений «странного» нового оператора и его аналога operator==, а также формирование некоторых рекомендаций по его использованию в повседневном кодинге.
Сравнение
Нет ничего необычного в том, чтобы увидеть код, подобный следующему:
struct IntWrapper {
int value;
constexpr IntWrapper(int value): value{value} { }
bool operator==(const IntWrapper& rhs) const { return value == rhs.value; }
bool operator!=(const IntWrapper& rhs) const { return !(*this == rhs); }
bool operator<(const IntWrapper& rhs) const { return value < rhs.value; }
bool operator<=(const IntWrapper& rhs) const { return !(rhs < *this); }
bool operator>(const IntWrapper& rhs) const { return rhs < *this; }
bool operator>=(const IntWrapper& rhs) const { return !(*this < rhs); }
};Примечание: внимательные читатели заметят, что это на самом деле даже менее многословно, чем должно быть в коде до версии C++20. Подробнее об этом позже.
Нужно написать много стандартного кода, чтобы убедиться, что наш тип сопоставим с чем-то такого же типа. Хорошо, мы разберемся с этим за какое-то время. Затем приходит кто-то, кто пишет так:
constexpr bool is_lt(const IntWrapper& a, const IntWrapper& b) {
return a < b;
}
int main() {
static_assert(is_lt(0, 1));
}Первое, что вы заметите, это то, что программа не будет компилироваться.
error C3615: constexpr function 'is_lt' cannot result in a constant expression
Проблема в том, что был забыт constexpr в функции сравнения. Затем некоторые добавят constexpr во все операторы сравнения. Несколько дней спустя кто-то добавит помощник is_gt, но заметит, что все операторы сравнения не имеют спецификации исключений, и придется проходить один и тот же утомительный процесс добавления noexcept к каждой из 5 перегрузок.
Именно здесь в помощь нам приходит новый оператор C++20 spaceship. Давайте посмотрим, как можно написать исходный IntWrapper в мире C++20:
#include <compare>
struct IntWrapper {
int value;
constexpr IntWrapper(int value): value{value} { }
auto operator<=>(const IntWrapper&) const = default;
};
Первое отличие, которое вы можете заметить — это новое включение <compare>. Заголовок <compare> отвечает за заполнение компилятора всеми типами категорий сравнения, необходимыми для оператора spaceship, чтобы он возвращал тип, подходящий для нашей дефолтной функции. В приведенном выше фрагменте тип возвращаемого значения auto будет std::strong_ordering.
Мы не только удалили 5 лишних строк, но нам даже не нужно ничего определять, компилятор сделает это за нас. is_lt остается неизменным и просто работает, оставаясь при этом constexpr, хотя мы не указали это явно в нашем дефолтном operator<=>. Это хорошо, но некоторые люди могут ломать голову над тем, почему is_lt разрешено компилировать, даже если он вообще не использует оператор spaceship. Давайте найдем ответ на этот вопрос.
Переписывание выражений
В C++20 компилятор вводится в новую концепцию, имеющую отношение к «переписанным» выражениям. Оператор spaceship, наряду с operator==, является одним из первых двух кандидатов, которые могут быть переписаны. Для более конкретного примера переписывания выражений давайте разберем пример, приведенный в is_lt.
Во время разрешения перегрузки компилятор будет выбирать из набора наиболее подходящих кандидатов, каждый из которых соответствует оператору, который нам нужен. Процесс отбора кандидатов изменяется очень незначительно для случая операций сравнения и операций эквивалентности, когда компилятор также должен собирать специальных переписанных и синтезированных кандидатов ([over.match.oper]/3.4).
Для нашего выражения a < b стандарт утверждает, что мы можем искать тип a для operator<=> или функции operator<=>, которые принимают этот тип. Так делает компилятор и обнаруживает, что на самом деле тип a содержит IntWrapper::operator<=>. Затем компилятору разрешается использовать этот оператор и переписать выражение a < b как (a <=> b) < 0. Это переписанное выражение затем используется в качестве кандидата для нормального разрешения перегрузки.
Вы можете спросить, почему это переписанное выражение является корректным. Правильность выражения фактически вытекает из семантики, которую обеспечивает оператор spaceship. <=> — это трехстороннее сравнение, которое подразумевает, что вы получаете не просто бинарный результат, но и порядок (в большинстве случаев). Если у вас есть порядок, вы можете выразить этот порядок в терминах любых операций сравнения. Быстрый пример, выражение 4 <=> 5 в C++20 вернет вам результат std::strong_ordering::less. Результат std::strong_ordering::less подразумевает, что 4 не только отличается от 5 но и строго меньше этого значения, что делает применение операции (4 <=> 5) < 0 правильным и точным для описания нашего результата.
Используя приведенную выше информацию, компилятор может взять любой обобщенный оператор сравнения (т.е. <, >, и т.д.) и переписать его в терминах оператора spaceship. В стандарте переписанное выражение часто упоминается как (a <=> b) @ 0 где @ представляет любую операцию сравнения.
Синтезирующие выражения
Читатели, возможно, заметили тонкое упоминание «синтезированных» выражений выше, и они также играют роль в этом процессе переписывания операторов. Рассмотрим следующую функцию:
constexpr bool is_gt_42(const IntWrapper& a) {
return 42 < a;
}
Если мы используем наше первоначальное определение для IntWrapper, этот код не будет компилироваться.
error C2677: binary '<': no global operator found which takes type 'const IntWrapper' (or there is no acceptable conversion)
Это имеет смысл до версии C++20, и способ решения этой проблемы заключается в добавлении некоторых дополнительных функций friend в IntWrapper , которые занимают левую сторону от int. Если вы попробуете построить этот пример с помощью компилятора и определения IntWrapper C++20, вы можете заметить, что он, опять же, просто работает. Давайте рассмотрим, почему приведенный выше код все еще компилируется в C++20.
Во время разрешения перегрузки компилятор также будет собирать то, что стандарт называет «синтезированными» кандидатами, или переписанным выражением с обратным порядком параметров. В приведенном выше примере компилятор попытается использовать переписанное выражение (42 <=> a) < 0, но обнаружит, что нет преобразования из IntWrapper в int, чтобы удовлетворить левую часть, так что переписанное выражение отбрасывается. Компилятор также вызывает «синтезированное» выражение 0 < (a <=> 42) и обнаруживает, что происходит преобразование из int в IntWrapper через его конструктор преобразования, поэтому этот кандидат используется.
Цель синтезированных выражений состоит в том, чтобы избежать путаницы в необходимости написания шаблонов функций friend , чтобы заполнить пробелы, в которых ваш объект может быть преобразован из других типов. Синтезированные выражения обобщаются до 0 @ (b <=> a).
Более сложные типы
Сгенерированный компилятором оператор spaceship не останавливается на отдельных членах классов, он генерирует правильный набор сравнений для всех подобъектов в ваших типах:
struct Basics {
int i;
char c;
float f;
double d;
auto operator<=>(const Basics&) const = default;
};
struct Arrays {
int ai[1];
char ac[2];
float af[3];
double ad[2][2];
auto operator<=>(const Arrays&) const = default;
};
struct Bases : Basics, Arrays {
auto operator<=>(const Bases&) const = default;
};
int main() {
constexpr Bases a = { { 0, 'c', 1.f, 1. },
{ { 1 }, { 'a', 'b' }, { 1.f, 2.f, 3.f }, { { 1., 2. }, { 3., 4. } } } };
constexpr Bases b = { { 0, 'c', 1.f, 1. },
{ { 1 }, { 'a', 'b' }, { 1.f, 2.f, 3.f }, { { 1., 2. }, { 3., 4. } } } };
static_assert(a == b);
static_assert(!(a != b));
static_assert(!(a < b));
static_assert(a <= b);
static_assert(!(a > b));
static_assert(a >= b);
}Компилятор знает, как развернуть члены классов, которые являются массивами, в их списки подобъектов и сравнить их рекурсивно. Конечно, если вы хотите написать тела этих функций самостоятельно, вы все равно получите пользу от переписывания выражений компилятором.
Выглядит как утка, плавает как утка, и крякает как operator==
Некоторые очень умные люди в комитете по стандартизации заметили, что оператор spaceship всегда будет выполнять лексикографическое сравнение элементов, несмотря ни на что. Безусловное выполнение лексикографических сравнений может привести к неэффективному коду, в частности, с оператором равенства.
Канонический пример со сравнением двух строк. Если у вас есть строка "foobar" и вы сравниваете ее со строкой "foo", используя ==, можно ожидать, что эта операция будет почти постоянной. Эффективный алгоритм сравнения строк следующий:
- Сначала сравните размер двух строк. Если размеры отличаются, то верните
false - В противном случае пошагово просматривайте каждый элемент двух строк и сравнивайте их до тех пор, пока не найдется отличие или не закончатся все элементы. Верните результат.
В соответствии с правилами оператора spaceship мы должны начать с сравнения каждого элемента, пока не найдем тот, который отличается. В нашем примере "foobar" и "foo" только при сравнении 'b' и '' вы наконец возвращаете false.
Для борьбы с этим была статья P1185R2, в которой подробно описывается, как компилятор переписывает и генерирует operator== независимо от оператора spaceship. Наш IntWrapper может быть написан следующим образом:
#include <compare>
struct IntWrapper {
int value;
constexpr IntWrapper(int value): value{value} { }
auto operator<=>(const IntWrapper&) const = default;
bool operator==(const IntWrapper&) const = default;
};
Еще один шаг… однако, есть хорошие новости; вам на самом деле не нужно писать код выше, потому что простого написания auto operator<=>(const IntWrapper&) const = default достаточно, чтобы компилятор неявно сгенерировал отдельный и более эффективный operator== для вас!
Компилятор применяет слегка измененное правило «перезаписи», специфичное для == и !=, где в этих операторах они переписываются в терминах operator==, а не operator<=>. Это означает, что != также выигрывает от оптимизации.
Старый код не сломается
В этот момент вы можете подумать: хорошо, если компилятору разрешено выполнять эту операцию переписывания операторов, что произойдет, если я попытаюсь перехитрить компилятор:
struct IntWrapper {
int value;
constexpr IntWrapper(int value): value{value} { }
auto operator<=>(const IntWrapper&) const = default;
bool operator<(const IntWrapper& rhs) const { return value < rhs.value; }
};
constexpr bool is_lt(const IntWrapper& a, const IntWrapper& b) {
return a < b;
}Ответ — вы не сможете. Модель разрешения перегрузки в C++ имеет арену, в которой сражаются все кандидаты. В этом конкретном сражении у нас есть 3 кандидата:
IntWrapper::operator<(const IntWrapper& a, const IntWrapper& b)IntWrapper::operator<=>(const IntWrapper& a, const IntWrapper& b)
(переписанный)
IntWrapper::operator<=>(const IntWrapper& b, const IntWrapper& a)
(синтезированный)
Если бы мы приняли правила разрешения перегрузки в C++17, результат этого вызова был бы неоднозначным, но правила разрешения перегрузки C++20 были изменены, чтобы компилятор мог разрешить эту ситуацию до наиболее логичной перегрузки.
Существует фаза разрешения перегрузки, когда компилятор должен выполнить серию тай-брейков. В C ++20 появился новый механизм тай-брейкинга, в рамках которого предпочтение отдается перегрузкам, которые не переписываются и не синтезируются, что делает нашу перегрузку IntWrapper::operator<лучшим кандидатом и разрешает неоднозначность. Этот же механизм предотвращает полное замещение регулярных переписанных выражений синтезированными кандидатами.
Заключительные мысли
Оператор spaceship является желанным дополнением к C++, поскольку сможет помочь упростить ваш код и писать его меньше, а иногда меньше — лучше. Так что пристегивайтесь и управляйте космическим кораблем C++20!
Мы призываем вас выйти и опробовать оператор spaceship, он доступен прямо сейчас в Visual Studio 2019 под /std:c++latest! Как примечание, изменения, внесенные в P1185R2, будут доступны в Visual Studio 2019 версии 16.2. Пожалуйста, имейте в виду, что оператор spaceship является частью C++20 и подвержен некоторым изменениям вплоть до того момента, когда C++20 будет финализирован.
Как всегда, мы ждем ваших отзывов. Не стесняйтесь присылать любые комментарии по электронной почте по адресу visualcpp@microsoft.com, через Twitter @visualc, или Facebook Microsoft Visual Cpp.
Если вы столкнулись с другими проблемами с MSVC в VS 2019, сообщите нам об этом через опцию «Сообщить о проблеме», либо из установщика, либо из самой Visual Studio IDE. Для предложений или сообщией об ошибках, пишите нам через DevComm.
Автор: Владимир Истомин
