В некоторых случаях это вопрос семантики. Это не очень очевидно с конструкторами по умолчанию, но становится очевидным с другими сгенерированными компилятором функциями-членами.
Для конструктора по умолчанию можно было бы сделать любой конструктор по умолчанию с пустым телом кандидатом в тривиальный конструктор, как и при использовании =default. В конце концов, старые пустые конструкторы по умолчанию были допустимы для C ++ .
struct S {
int a;
S() {} // legal C++
};
То, понимает ли компилятор этот конструктор как тривиальный, в большинстве случаев не имеет значения, кроме оптимизаций (ручных или компиляционных).
Тем не менее, эта попытка обработать пустые тела функций как «по умолчанию» не работает для других типов функций-членов. Рассмотрим конструктор копирования:
struct S {
int a;
S() {}
S(const S&) {} // legal, but semantically wrong
};
В приведенном выше случае конструктор копирования, написанный с пустым телом, теперь неверен . Он больше ничего не копирует. Этот набор семантик сильно отличается от семантики конструктора копирования по умолчанию. Желаемое поведение требует, чтобы вы написали код:
struct S {
int a;
S() {}
S(const S& src) : a(src.a) {} // fixed
};
Однако даже в этом простом случае для компилятора становится гораздо сложнее проверять, что конструктор копирования идентичен тому, который он генерирует сам, или видеть, что конструктор копирования тривиален (эквивалентен memcpy, в основном ). Компилятор должен будет проверить каждое выражение инициализатора члена и убедиться, что оно идентично выражению, чтобы получить доступ к соответствующему члену источника и ни к чему другому, убедиться, что ни один член не остался с нетривиальной конструкцией по умолчанию и т. Д. Это происходит в обратном направлении в процессе компилятор будет использовать для проверки того, что собственные сгенерированные версии этой функции тривиальны.
Затем рассмотрим оператор присваивания копии, который может стать еще более привлекательным, особенно в нетривиальном случае. Это тонна изобилия, который вам не нужно писать для многих классов, но вы все равно будете вынуждены писать на C ++ 03:
struct T {
std::shared_ptr<int> b;
T(); // the usual definitions
T(const T&);
T& operator=(const T& src) {
if (this != &src) // not actually needed for this simple example
b = src.b; // non-trivial operation
return *this;
};
Это простой случай, но это уже больше кода, чем вы когда-либо хотели бы написать для такого простого типа, как T(особенно когда мы бросаем операции перемещения в смесь). Мы не можем полагаться на пустое тело, означающее «заполнить значения по умолчанию», потому что пустое тело уже совершенно правильно и имеет ясное значение. Фактически, если бы пустое тело использовалось для обозначения «заполнения значений по умолчанию», то не было бы никакого способа явно создать конструктор копирования без операции или тому подобное.
Это опять вопрос последовательности. Пустое тело означает «ничего не делать», но для таких вещей, как конструкторы копирования, вы действительно не хотите «ничего не делать», а «делайте все, что вы обычно делаете, если не подавлены». Отсюда =default. Это необходимо для преодоления подавленных функций-членов, генерируемых компилятором, таких как конструкторы копирования / перемещения и операторы присваивания. Тогда просто «очевидно» заставить его работать и для конструктора по умолчанию.
Было бы неплохо сделать конструктор по умолчанию с пустыми телами, а тривиальные члены / базовые конструкторы также можно считать тривиальными, как если бы они =defaultделали старый код более оптимальным в некоторых случаях, но большинство низкоуровневого кода полагалось на тривиальные конструкторы по умолчанию для оптимизации также опираются на тривиальные конструкторы копирования. Если вам нужно пойти и «исправить» все ваши старые конструкторы копирования, вам также не составит труда исправить все ваши старые конструкторы по умолчанию. Это также намного яснее и очевиднее, если использовать явное =defaultдля обозначения ваших намерений.
Есть еще несколько вещей, которые будут выполнять функции-члены, созданные компилятором, и вам также придется явно вносить изменения для поддержки. Поддержка constexprконструкторов по умолчанию является одним из примеров. Это просто проще мысленно использовать, =defaultчем размечать функции всеми другими специальными ключевыми словами и такими, которые подразумеваются, =defaultи это была одна из тем C ++ 11: сделать язык проще. В нем все еще есть много недостатков и компромиссов, но ясно, что это большой шаг вперед по сравнению с C ++ 03, когда дело касается простоты использования.
defaultне новое ключевое слово, это просто новое использование уже зарезервированного ключевого слова.