Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Les destructeurs dans MQL5 sont toujours virtuels. Tout est supprimé correctement, essayez de mettre Print(__FUNCSIG__) ; dans les destructeurs.
Je l'ai fait en VC++, mais je pense que les mécanismes de libération de la mémoire sont les mêmes ?
Mais votre exemple fonctionnera correctement, car vous pouvez spécifier le destructeur virtuel uniquement pour la classe de base.
Je vais essayer de présenter l'idée d'une manière légèrement différente :
Étant donné :
Actions :
P.S. : la figure montre le modèle de mémoire )
Doutes car le pointeur de la classe numéro un et en fait en mémoire la classe numéro deux. Cela compte dans le cas des destructeurs, et je me demandais donc s'il n'y avait pas un problème ici aussi. Je pense que dans une telle situation, la libération correcte de la mémoire ne peut se faire que s'il y a des étiquettes en mémoire (comme un caractère avec un terminateur zéro) ou quelque chose comme ça, c'est pourquoi j'ai posé la question de l'allocation de mémoire.
Votre doute vient du fait que vous n'avez pas spécifié les constructeurs (il est important de comprendre ce qui se passe dans ce cas), essayez d'exécuter cet exemple et vous comprendrez tout :
HZ la construction elle-même ainsi que la suppression sont échelonnées, et toutes ces informations sont stockées (le pointeur virtuel lui-même se souvient que la classe a été construite comme un composite de la base et du descendant), et lors de la suppression, les destructeurs sont appelés dans l'ordre inverse, du plus récent au plus ancien.
Il ne s'agit pas des destructeurs, mais de la classe elle-même, et plus précisément du nombre d'octets qu'elle occupe. Il s'avère qu'on alloue 200 octets et qu'on me dit ensuite de libérer la mémoire pointée par le pointeur représentant l'objet de taille 100 octets.
Oui, le pool de mémoire sait combien de temps un morceau de mémoire sera libéré par un appel de suppression.
L'endroit où cette information est stockée dépend de l'implémentation du pool.
Par exemple, si vous donnez un pointeur à un objet en C++ qui n'est pas alloué par new, vous verrez comment votre application se plantera.
Il ne s'agit pas des destructeurs, mais de la classe elle-même, et plus précisément du nombre d'octets qu'elle occupe. Il s'avère qu'on alloue 200 octets et qu'on me dit ensuite de libérer la mémoire pointée par le pointeur représentant l'objet de taille 100 octets.
Je comprends que votre question concerne la façon dont le pool de mémoire fonctionne.
Oui, le pool de mémoire sait combien de temps un morceau sera libéré par un appel de suppression.
L'endroit où cette information est stockée dépend de l'implémentation du pool.
Par exemple, si vous donnez un pointeur à un objet en C++ qui n'a pas été alloué par new, vous verrez comment votre application se plantera.