W niektórych przypadkach jest to kwestia semantyki. Nie jest to zbyt oczywiste w przypadku domyślnych konstruktorów, ale staje się oczywiste w przypadku innych funkcji składowych generowanych przez kompilator.
W przypadku konstruktora domyślnego byłoby możliwe, aby każdy domyślny konstruktor z pustym ciałem był uważany za kandydata do bycia konstruktorem trywialnym, tak samo jak using =default. W końcu stare puste domyślne konstruktory były legalne w C ++ .
struct S {
int a;
S() {} // legal C++
};
To, czy kompilator rozumie, że ten konstruktor jest trywialny, w większości przypadków nie ma znaczenia poza optymalizacjami (ręcznymi lub kompilatorowymi).
Jednak ta próba traktowania pustych treści funkcji jako „domyślnych” nie działa całkowicie na inne typy funkcji składowych. Rozważmy konstruktor kopiujący:
struct S {
int a;
S() {}
S(const S&) {} // legal, but semantically wrong
};
W powyższym przypadku konstruktor kopiujący napisany z pustą treścią jest teraz nieprawidłowy . To już nie jest kopiowanie niczego. Jest to zupełnie inny zestaw semantyki niż domyślna semantyka konstruktora kopiującego. Pożądane zachowanie wymaga napisania kodu:
struct S {
int a;
S() {}
S(const S& src) : a(src.a) {} // fixed
};
Jednak nawet w tym prostym przypadku staje się znacznie większym obciążeniem dla kompilatora, aby sprawdzić, czy konstruktor kopiujący jest identyczny z tym, który sam wygenerowałby, lub aby zobaczyć, że konstruktor kopiujący jest trywialny (odpowiednikmemcpy , w zasadzie ). Kompilator musiałby sprawdzić każde wyrażenie inicjalizujące element członkowski i upewnić się, że jest identyczne z wyrażeniem, aby uzyskać dostęp do odpowiedniego elementu członkowskiego źródła i nic więcej, upewnić się, że żaden element członkowski nie został pozostawiony z nietrywialną domyślną konstrukcją itp. Jest to wsteczna droga procesu kompilator użyłby do sprawdzenia, czy jego własne wygenerowane wersje tej funkcji są trywialne.
Rozważmy zatem operator przypisania kopiowania, który może być jeszcze bardziej skomplikowany, zwłaszcza w nietrywialnym przypadku. To mnóstwo gotowej płyty, której nie chcesz pisać dla wielu klas, ale i tak jesteś do tego zmuszony w 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;
};
To prosty przypadek, ale jest to już więcej kodu, niż kiedykolwiek chciałbyś być zmuszony do pisania dla tak prostego typu T(zwłaszcza gdy wrzucimy operacje przenoszenia do miksu). Nie możemy polegać na pustym treści oznaczającym „wypełnij wartości domyślne”, ponieważ puste ciało jest już w pełni poprawne i ma jasne znaczenie. W rzeczywistości, gdyby puste ciało zostało użyte do oznaczenia „wypełnij wartości domyślne”, nie byłoby sposobu na jawne utworzenie konstruktora kopiującego bez operacji lub podobnego.
To znowu kwestia spójności. Puste ciało oznacza „nic nie rób”, ale w przypadku takich rzeczy, jak konstruktory kopiujące, naprawdę nie chcesz „nic nie robić”, a raczej „robić wszystko, co normalnie robisz, jeśli nie jest to wstrzymane”. Stąd =default. Jest to konieczne do przezwyciężenia pominiętych funkcji składowych generowanych przez kompilator, takich jak konstruktory kopiowania / przenoszenia i operatory przypisania. Wtedy jest to po prostu „oczywiste”, aby działał również dla domyślnego konstruktora.
Byłoby fajnie, gdyby domyślny konstruktor z pustymi treściami i trywialnymi konstruktorami składowymi / bazowymi również był uważany za trywialne, tak jak byłyby =defaultw niektórych przypadkach, gdyby tylko uczynić starszy kod bardziej optymalnym w niektórych przypadkach, ale większość kodu niskiego poziomu opiera się na trywialnych domyślne konstruktory do optymalizacji również opierają się na trywialnych konstruktorach kopiujących. Jeśli będziesz musiał iść i "naprawić" wszystkie swoje stare konstruktory kopiowania, naprawianie wszystkich starych domyślnych konstruktorów nie jest zbyt trudne. O wiele jaśniejsze i bardziej oczywiste jest również użycie wyraźnego =defaultwyrażenia, aby wskazać swoje intencje.
Jest jeszcze kilka innych rzeczy, które będą robione przez funkcje składowe generowane przez kompilator, a które będziesz musiał jawnie wprowadzić zmiany w obsłudze. Wspieranie constexprdla domyślnych konstruktorów jest jednym z przykładów. Jest to po prostu łatwiejsze w użyciu psychicznie =defaultniż konieczność oznaczania funkcji wszystkimi innymi specjalnymi słowami kluczowymi i takimi, które są implikowane =defaulti było jednym z tematów C ++ 11: uczynić język łatwiejszym. Wciąż ma wiele brodawek i kompromisów z kompatybilnością wsteczną, ale jasne jest, że jest to duży krok naprzód w stosunku do C ++ 03, jeśli chodzi o łatwość użycia.
defaultnie jest nowym słowem kluczowym, jest po prostu nowym użyciem już zarezerwowanego słowa kluczowego.