È una questione di semantica in alcuni casi. Non è molto ovvio con i costruttori predefiniti, ma diventa evidente con altre funzioni membro generate dal compilatore.
Per il costruttore predefinito, sarebbe stato possibile rendere qualsiasi costruttore predefinito con un corpo vuoto essere considerato un candidato per essere un costruttore banale, come usare =default. Dopotutto, i vecchi costruttori predefiniti vuoti erano C ++ legali .
struct S {
int a;
S() {} // legal C++
};
Il fatto che il compilatore capisca o meno che questo costruttore sia banale è irrilevante nella maggior parte dei casi al di fuori delle ottimizzazioni (manuali o del compilatore).
Tuttavia, questo tentativo di considerare i corpi di funzione vuoti come "predefiniti" si interrompe completamente per altri tipi di funzioni membro. Considera il costruttore della copia:
struct S {
int a;
S() {}
S(const S&) {} // legal, but semantically wrong
};
Nel caso precedente, il costruttore di copie scritto con un corpo vuoto è ora sbagliato . In realtà non sta più copiando nulla. Questo è un insieme molto diverso di semantica rispetto alla semantica predefinita del costruttore di copie. Il comportamento desiderato richiede di scrivere del codice:
struct S {
int a;
S() {}
S(const S& src) : a(src.a) {} // fixed
};
Anche con questo semplice caso, tuttavia, sta diventando molto più un onere per il compilatore verificare che il costruttore di copie sia identico a quello che si genererebbe o per vedere che il costruttore di copie è banale (equivalente a unmemcpy , sostanzialmente ). Il compilatore dovrebbe controllare l'espressione di ogni inizializzatore del membro e assicurarsi che sia identico all'espressione per accedere al membro corrispondente del sorgente e nient'altro, assicurarsi che nessun membro rimanga con una costruzione predefinita non banale, ecc. È indietro in un modo del processo il compilatore userebbe per verificare che le proprie versioni generate di questa funzione siano banali.
Considera quindi l'operatore di assegnazione delle copie che può diventare ancora più peloso, specialmente nel caso non banale. È una tonnellata di boiler-plate che non vuoi scrivere per molte classi, ma sei comunque obbligato a farlo in 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;
};
Questo è un caso semplice, ma è già più codice di quanto vorresti mai essere costretto a scrivere per un tipo così semplice come T(specialmente una volta che lanciamo operazioni di spostamento nel mix). Non possiamo fare affidamento su un corpo vuoto che significa "riempire i valori predefiniti" perché il corpo vuoto è già perfettamente valido e ha un significato chiaro. In effetti, se il corpo vuoto fosse usato per indicare "riempire i valori predefiniti", non ci sarebbe modo di creare esplicitamente un costruttore di copie non operative o simili.
È di nuovo una questione di coerenza. Il corpo vuoto significa "non fare nulla" ma per cose come i costruttori di copie non vuoi davvero "non fare nulla" ma piuttosto "fai tutte le cose che normalmente faresti se non fossero soppresse". Quindi =default. È necessario per superare funzioni membro generate dal compilatore soppresse come costruttori di copia / spostamento e operatori di assegnazione. È quindi "ovvio" farlo funzionare anche per il costruttore predefinito.
Sarebbe stato bello rendere il costruttore predefinito con corpi vuoti e anche i costruttori banali di membri / base fossero considerati banali proprio come lo sarebbero stati =defaultse solo per rendere il codice più vecchio più ottimale in alcuni casi, ma la maggior parte del codice di basso livello si basava su banale i costruttori predefiniti per le ottimizzazioni si basano anche su costruttori di copie banali. Se devi andare a "riparare" tutti i tuoi vecchi costruttori di copie, in realtà non è un granché dover riparare tutti i tuoi vecchi costruttori predefiniti. È anche molto più chiaro e più ovvio usare un esplicito =defaultper indicare le tue intenzioni.
Ci sono alcune altre cose che faranno le funzioni membro generate dal compilatore che dovresti anche fare esplicitamente modifiche per supportare. Il supporto constexprper i costruttori predefiniti è un esempio. È solo più facile da usare mentalmente =defaultche dover contrassegnare le funzioni con tutte le altre parole chiave speciali e tali che sono implicite =defaulte che era uno dei temi di C ++ 11: rendere il linguaggio più semplice. Ha ancora molte verruche e compromessi per la retrocompatibilità, ma è chiaro che è un grande passo avanti rispetto a C ++ 03 quando si tratta di facilità d'uso.
defaultnon è una nuova parola chiave, è semplicemente un nuovo uso di una parola chiave già riservata.