La nouvelle syntaxe “ = ” par défaut en C++11

Un défaut constructeur par défaut est expressément défini comme étant le même que définis par l'utilisateur dans le constructeur par défaut sans liste d'initialisation et un vide instruction composée.

§12.1/6 [classe.ctor] Un constructeur par défaut qui est, par défaut, et n'est pas définie comme étant supprimés est implicitement défini lorsqu'il est odr-utilisé pour créer un objet de sa classe, type ou lorsqu'il est explicitement fait défaut après sa première déclaration. La implicitement par défaut définis par le constructeur effectue l'ensemble de l'initialisation de la classe qui serait effectuée par un utilisateur écrit dans le constructeur par défaut pour la classe sans ctor-initialiseur (12.6.2) et un vide composé de l'instruction. [...]

Cependant, alors que les deux constructeurs se comportera de la même, de fournir un vide de mise en œuvre ne touchent que certaines propriétés de la classe. Donner un utilisateur défini par le constructeur, même si elle ne fait rien, fait pas un globale et aussi de ne pas trivial. Si vous voulez que votre classe soit un agrégat ou un trivial type (ou par transitivité, un type POD), alors vous devez utiliser = default.

§8.5.1/1 [dcl.init.aggr] Un agrégat est un tableau ou une classe sans que l'utilisateur fourni par les constructeurs, [et...]

§12.1/5 [classe.ctor] Un constructeur par défaut est trivial si il n'est pas fourni par l'utilisateur et [...]

§9/6 [classe] trivial classe est une classe qui a un trivial constructeur par défaut et [...]

À démontrer:

#include <type_traits>

struct X {
    X() = default;
};

struct Y {
    Y() { };
};

int main() {
    static_assert(std::is_trivial<X>::value, "X should be trivial");
    static_assert(std::is_pod<X>::value, "X should be POD");

    static_assert(!std::is_trivial<Y>::value, "Y should not be trivial");
    static_assert(!std::is_pod<Y>::value, "Y should not be POD");
}

En outre, de manière explicite à défaut d'un constructeur de faire constexpr si le constructeur implicite auraient été et de donner également à la même spécification d'exception que l'implicite constructeur aurait eu. Dans le cas où vous avez donné, de l'implicite constructeur n'aurait pas été constexpr (car il laisserait un membre de données non initialisées) et il aurait aussi un vide spécification d'exception, donc il n'y a pas de différence. Mais oui, dans le cas général, vous pourriez spécifier manuellement constexpr et la spécification d'exception pour correspondre à l'implicite du constructeur.

À l'aide de = default apporte une certaine uniformité, parce qu'il peut également être utilisé avec des copier/déplacer des constructeurs et des destructeurs. Un vide constructeur de copie, par exemple, ne fera pas la même chose qu'un défaut constructeur de copie (qui effectuera des états-sage copie de ses membres). À l'aide de la = default (ou = delete) syntaxe uniforme pour chacune de ces fonctions de membre rend votre code plus facile à lire, en indiquant expressément à votre intention.

C'est une question de sémantique dans certains cas. Il n'est pas très évident avec les constructeurs par défaut, mais il devient évident avec d'autres généré par le compilateur des fonctions de membre du.

Pour le constructeur par défaut, il aurait été possible de faire tout constructeur par défaut avec un vide de corps être considéré comme un candidat pour un trivial constructeur, de même que l'utilisation de =default. Après tout, l'ancien vide constructeurs par défaut ont été juridique C++.

struct S { 
  int a; 
  S() {} //legal C++ 
};

De savoir si ou non le compilateur comprend ce constructeur pour être trivial est pas pertinent dans la plupart des cas en dehors des optimisations (manuel ou le compilateur ceux).

Cependant, cette tentative pour traiter les vide le corps des fonctions comme "par défaut" se décompose entièrement pour d'autres types de fonctions membres. Envisager le constructeur de copie:

struct S { 
  int a; 
  S() {}
  S(const S&) {} //legal, but semantically wrong
};

Dans le cas ci-dessus, le constructeur de copie écrite avec un vide corps est maintenant mal. Il n'est plus fait de copier quoi que ce soit. C'est un ensemble très différent de la sémantique de la valeur par défaut constructeur de copie de la sémantique. Le comportement souhaité vous oblige à écrire un peu de code:

struct S { 
  int a; 
  S() {}
  S(const S& src) : a(src.a) {} //fixed
};

Même dans ce cas simple, cependant, il devient beaucoup plus un fardeau pour le compilateur de vérifier que le constructeur de copie est identique à celui qu'elle génère elle-même ou pour elle de voir que le constructeur de copie est trivial (équivalent à un memcpy, essentiellement). Le compilateur aurait pour vérifier que chaque membre de l'initialiseur d'expression et de s'assurer qu'il est identique à l'expression d'accéder à la source de membre correspondant, et rien d'autre, assurez-vous qu'aucun des membres sont laissés par défaut non trivial de construction, etc. C'est dans une arrière manière de processus le compilateur pourrait utiliser pour vérifier qu'il est propre généré versions de cette fonction est trivial.

Considérons alors la copie opérateur d'affectation qui peut être encore plus poilu, en particulier dans les cas trivial. C'est une tonne de chaudière-plaque que vous ne voulez pas avoir à écrire pour de nombreuses classes, mais vous êtes pas obligés de toute façon en 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;
};

Qui est un cas simple, mais c'est déjà plus de code que vous souhaitez toujours être forcé à écrire pour un type simple comme T (surtout une fois que nous lancions des opérations de déplacement dans le mélange). Nous ne pouvons pas compter sur un corps est vide de sens ", remplissez les paramètres par défaut", parce que le vide, le corps est déjà parfaitement valide et a une signification claire. En fait, si le corps est vide ont été utilisés pour désigner à compléter "par défaut", alors il n'y aurait pas moyen de faire explicitement un no-op constructeur de copie ou similaires.

C'est de nouveau une question de cohérence. Le corps est vide signifie "ne rien faire", mais pour des choses comme la copie constructeurs, vous ne voulez vraiment pas "ne rien faire" mais plutôt de "faire toutes les choses que vous auriez normalement faire si pas supprimé." Donc =default. C'est nécessaire pour surmonter supprimé généré par le compilateur membre, comme les fonctions de copier/déplacer des constructeurs et des opérateurs d'affectation. Il est il est "évident" pour le faire fonctionner pour le constructeur par défaut ainsi.

Il aurait été sympa de faire de constructeur par défaut avec des corps vides et trivial membre/de la base de constructeurs aussi être considérées comme banales, comme ils l'ont été avec =default si ce n'est pour faire de vieux code plus optimale dans certains cas, mais la plupart à faible niveau de code en s'appuyant sur trivial constructeurs par défaut pour les optimisations s'appuie également sur trivial copie des constructeurs. Si vous allez avoir à aller et corriger tous vos vieux copier les constructeurs, c'est vraiment pas beaucoup d'un tronçon d'avoir à résoudre tous vos vieux constructeurs par défaut, soit. Il est aussi beaucoup plus clair et plus évident à l'aide d'un explicite =default pour désigner vos intentions.

Il ya quelques autres choses que généré par le compilateur fonctions de membre fera que vous auriez à faire explicitement les changements à l'appui, ainsi. Soutenir constexpr pour les constructeurs par défaut est un exemple. C'est juste plus facile mentalement à utiliser =default que d'avoir à marquer les fonctions avec tous les autres mots-clés spéciales et tels qui sont implicites =default et qui a été l'un des thèmes de C++11: rendre la langue plus facile. Il a encore beaucoup de verrues et de l'arrière-compat compromis, mais il est clair que c'est un grand pas en avant à partir de C++03 quand il s'agit de la facilité d'utilisation.