Pourquoi est-ce que C++, un utilisateur par défaut fourni par le constructeur pour défaut de construire un const objet?

Cela a été considéré comme un défaut (à l'encontre de toutes les versions de la norme) et il a été résolu par De base Groupe de Travail (GTC) Défaut 253. La nouvelle formulation de la norme en http://eel.is/c++projet/dcl.init#7

Une classe de type T est const-par défaut-si constructible
par défaut-initialisation de T pourrait appeler un utilisateur fourni par le constructeur
de T (pas hérité d'une classe de base) ou si

• chaque directe non-variante non-membre de données statiques M de T a un défaut d'initialiseur de membre ou, si M est de type classe X (ou tableau de celui-ci), X
  est const-par défaut-constructible,
• si T est une union avec au moins un non-membre de données statiques, exactement une variante membre a un membre par défaut de l'initialiseur,
• si T n'est pas un syndicat, pour chaque anonymes membre de l'union avec au moins un non-membre de données statiques (le cas échéant), un non-statique de données
  membre dispose d'un membre par défaut de l'initialiseur, et
• chaque potentiellement construit de la classe de base de T est const-par défaut-constructible.

Si un programme appelle à la valeur par défaut-initialisation d'un objet d'une
const qualifiés de type T, T est un const-par défaut-classe constructible
type de tableau ou de celle-ci.

Cette formulation signifie essentiellement que l'évident code fonctionne. Si vous initialisez l'ensemble de vos bases et les membres, vous pouvez dire A const a; peu importe comment ou si vous sort tout les constructeurs.

struct A {
};
A const a;

gcc a accepté ce depuis 4.6.4. clang a accepté ce depuis 3.9.0. Visual Studio accepte également (au moins en 2017, ne sais pas si tôt).

De la Pure spéculation de ma part, mais considérer que les autres types de restriction semblable, trop:

int main()
{
    const int i; //invalid
}

N'est donc pas seulement cette règle homogène, mais aussi (de manière récursive) empêche non const (sous -) objets:

struct X {
    int j;
};
struct A {
    int i;
    X x;
}

int main()
{
    const A a; //a.i and a.x.j in unitialized states!
}

Comme pour l'autre côté de la question (en l'autorisant pour les types avec un constructeur par défaut), je pense que l'idée est qu'un type avec un utilisateur par défaut fourni par le constructeur est censé toujours être dans un certain état cohérent après la construction. Notez que les règles qu'ils sont de permettre la suivante:

struct A {
    explicit
    A(int i): initialized(true), i(i) {} //valued constructor

    A(): initialized(false) {}

    bool initialized;
    int i;
};

const A a; //class invariant set up for the object
           //yet we didn't pay the cost of initializing a.i

Alors on pourrait peut-être formuler une règle comme "au moins un membre doit être intelligemment initialisé à un utilisateur par défaut fourni par le constructeur', mais c'est beaucoup trop de temps passé à essayer de se protéger contre Murphy. C++ a tendance à faire confiance au programmeur sur certains points.

Je regardais Timur Doumler de parler à la Réunion C++ 2018 et j'ai enfin compris pourquoi la norme exige qu'un utilisateur fourni par le constructeur ici, et non pas simplement un utilisateur déclaré. Il a à voir avec les règles de valeur d'initialisation.

Considérons deux classes: A a un l'utilisateur déclaré constructeur, B a un fourni par l'utilisateur constructeur:

struct A {
    int x;
    A() = default;
};
struct B {
    int x;
    B() {}
};

À première vue, vous pourriez penser que ces deux constructeurs se comporte de la même. Mais à voir la façon dont la valeur d'initialisation se comporte différemment, tout seul défaut initialisation se comporte de la même:

• A a; est par défaut d'initialisation: le membre int x est non initialisée.
• B b; est par défaut d'initialisation: le membre int x est non initialisée.
• A a{}; est la valeur d'initialisation: le membre int x est zéro-initialisé.
• B b{}; est la valeur d'initialisation: le membre int x est non initialisée.

Maintenant voir ce qui se passe quand on ajoute const:

• const A a; est par défaut d'initialisation: c'est mal formé en raison de la règle citée dans la question.
• const B b; est par défaut d'initialisation: le membre int x est non initialisée.
• const A a{}; est la valeur d'initialisation: le membre int x est zéro-initialisé.
• const B b{}; est la valeur d'initialisation: le membre int x est non initialisée.

Un non initialisée const scalaire (par exemple, la int x membre) serait inutile: il est écrit mal formé (parce que c'est const) et la lecture de c'est UB (parce que c'est une valeur indéterminée). Donc, cette règle ne vous empêche de créer une telle chose, en vous forçant à soit ajouter un initialiser ou opt-in pour les comportements dangereux par l'ajout d'un utilisateur fourni par le constructeur.

Je pense qu'il serait agréable d'avoir un attribut comme [[uninitialized]] pour indiquer au compilateur lorsque vous êtes intentionnellement pas de l'initialisation d'un objet. Nous ne serions pas obligés de faire de notre classe pas trivialement par défaut constructible à obtenir autour de ce coin de cas.