Opération d'affectation dans les listes d'initialiseurs de membres

Depuis la page Cppreference.com sur constructeurs :

Les noms qui apparaissent dans la liste d'expressions ou d'accolade-init-list sont évalués dans la portée du constructeur:

Alors oui, size fait ici référence à this-> size dans le périmètre du constructeur, et à l'affectation size = s.size est une expression valide.

Il va sans dire que vous ne devriez pas vous attendre à ce que cela passe une révision du code :)

Les membres d'une classe sont toujours initialisés dans l'ordre de déclaration, quel que soit l'ordre dans lequel vous les spécifiez dans la liste d'initialisation des membres. Et si vous les omettez, ils sont initialisés par défaut. Donc faire ceci:

Stack(const Stack& s) : x(new int[size=s.size]) {}

Signifie que la taille est initialisée par défaut en premier. Cela lui laisse une valeur indéterminée (car les types fondamentaux sont supposés être initialisés par défaut). Ensuite, l'initialiseur pour x est évalué. Une partie de l'évaluation de new int [size = s.size] implique l'expression d'affectation size = s.size , qui modifie size en tant qu'effet secondaire . Donc, votre code est correct ici, bien qu'il soit susceptible de soulever des sourcils.

Lorsque vous changez l'ordre des membres, l'attribution se produit avant taille code > est censé être initialisé. Cela laisse votre code ouvert à un comportement indéfini.

Le compilateur réécrit-il automatiquement le compilateur avec cela?

Stack(const Stack& s) : size(s.size), x(new int[s.size]) {}

No.

Stack(const Stack& s) : size(), x(new int[size=s.size]) {}

peut être considéré comme étant

Stack(const Stack& s) : x(new int[size=s.size]) {}

mais ce n'est pas vraiment depuis l'écriture size () valoriserait l'initialiser, ce qui signifie qu'il est initialisé à zéro, mais comme c'est le compilateur qui synthétise l'initialisation, l'initialisation par défaut ^[1] se produit, ce qui signifie qu'il n'est pas initialisé. Ensuite, vous lui attribuez une valeur lors de l'initialisation de x . C'est "sûr", ce qui signifie que cela fonctionne dans ce cas, mais je ne le recommanderais pas.

Stack(const Stack& s) : size(s.size), x(new int[size]) {}

initialise les deux membres et si jamais vous changez leur ordre dans la classe, vous aurez toujours le bon comportement.

Non, il le réécrit comme suit:

class Stack{
public:
    int size;
    int* x;
    Stack() : size(10), x(new int[10]) {}
    Stack(const Stack& s) :size(), x(new int[size=s.size]) {}
};

size () serait un constructeur par défaut pour l'objet size mais int s n'en a pas, donc c'est juste une instruction vide et size reste non initialisé. Ou est-ce le cas?

Je dirais que ce code peut générer un comportement indéfini. Les variables membres sont initialisées dans l'ordre dans lequel elles sont déclarées selon 10.9.2 Initialisation bases et membres . Mais l'ordre d'évaluation des expressions utilisées pour l'initialisation n'est pas défini. Ainsi, size = s.size peut être appelé avant ou après size () . Pour les types de classe, cela poserait un problème, mais je ne suis pas sûr que size () soit garanti sans opération et si le compilateur pourrait décider d'initialiser la variable par ex. 0.