La première situation :
Lors de la création d'un tableau d'objets C++, si assigné via la liste d'initialisation, des variables temporaires seront générées, mais pourquoi le destructeur n'est-il pas appelé
Le code est le suivant :
#include <iostream>
using namespace std;
class Point
{ public:
Point():x(0),y(0)
{ cout<<"Default Constructor called.\n";}
Point(int xx,int yy):x(xx),y(yy)
{ cout<< "Constructor called.\n"; }
~Point()
{ cout<<"Destructor called.\n"; }
void Move(int xx,int yy) { x=xx; y=yy; }
private:
int x,y;
};
int main()
{
Point A[2]={Point(1,2),Point()};
cout<<"hello"<<endl;
return 0;
}Le résultat de sortie est :
Parmi eux, Point A[2]={Point(1,2),Point()}; initialise le tableau d'objets A via deux variables temporaires. Pourquoi le destructeur n'est-il pas appelé pour le détruire ? ces deux objets temporaires.
Deuxième cas :
Si vous appelez explicitement le constructeur pour chaque élément du tableau, le destructeur sera automatiquement appelé :
Le code est le suivant :
#include <iostream>
using namespace std;
class B
{
int x, y;
public:
B();
B(int i);
B(int i, int j);
~B();
void Print();
};
B::B() :x(0), y(0)
{
cout << "Default constructor called.\n";
}
B::B(int i) : x(i), y(0)
{
cout << "Constructor 1 called.\n";
}
B::B(int i, int j) : x(i), y(j)
{
cout << "Constructor 2 called.\n";
}
B::~B()
{
cout << "Destructor called.\n";
}
void B::Print()
{
cout << "x=" << x << ", y=" << y << endl;
}
int main()
{
B *p;
p = new B[3];
cout << "*******" << endl;
p[0] = B();
p[1] = B(7);
p[2] = B(5, 9);
for (int i = 0; i < 3; i++)
p[i].Print();
cout << "*******" << endl;
delete[]p;
}
Les résultats en cours sont les suivants : 
On peut voir qu'après avoir appelé l'initialisation du constructeur pour chaque élément du tableau, la variable temporaire est détruite.
En résumé, les deux cas sont des variables temporaires, mais pourquoi l'un sera automatiquement détruit et l'autre pas, veuillez le résoudre ! ! !
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
J'ai vérifié à nouveau les informations et je me suis entraîné moi-même pour corriger l'erreur
Raison : L'affectation d'objet consiste à copier les valeurs des membres de l'objet de droite vers l'objet de gauche, puis de libérer l'objet de droite
—————— ————
Chaque fois que B() est appelé (avec ou sans paramètres), un objet temporaire est créé
Cas 1. L'objet temporaire (enregistré dans A) ne se voit pas attribuer de valeur après lui est créé, il n'y a donc aucun moyen de libérer l'objet sur le bon processus, l'objet dans A survit jusqu'à la fin de main()
Cas 2. Attribuez une valeur au tableau p, créez un objet temporaire et attribuez-le au objet original. L'objet original (c'est-à-dire l'objet temporaire créé automatiquement lors de l'initialisation de p) est uniquement attribué, à droite. La variable temporaire sur le côté est détruite et l'objet temporaire enregistré dans p est détruit lors de la suppression
————— —————
Quant à la raison pour laquelle la variable temporaire sur le côté droit de A n'est pas détruite, vous pouvez essayer de la construire. Affichez ceci dans la fonction, puis affichez la référence à l'objet enregistré dans A et vous le saurez. S'il y a des erreurs ou si vous ne comprenez pas, veuillez le signaler et je le corrigerai ou y répondrai à temps
1. La durée de vie de la variable d'application de l'espace de pile sera détruite lorsqu'elle dépassera la portée. Cette portée est dans la fonction principale.
2. Supprimer va de soi. Tout d'abord, B[3] est aussi un espace de pile, mais une fois réaffecté, la mission est terminée et doit être recyclée dès que possible.
Le tableau A est une variable locale de la fonction, et la mémoire est allouée dans la zone de pile. Point(1,2) et Point() sont également des variables locales et sont également allouées dans la zone de pile. À ce stade, le compilateur effectue généralement une optimisation pour réduire le recyclage et l'allocation de mémoire.
L'espace mémoire du tableau p est alloué dynamiquement et est situé dans la zone du tas. B(0), B(7), B(5, 9) sont des variables locales allouées sur la zone de pile.
Les emplacements d'allocation de mémoire des deux parties sont différents et le compilateur ne peut pas l'optimiser, il ne peut donc que le détruire honnêtement.