Questions d'un "mannequin - page 107

[[Supprimé]]

mql5:
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, non ?

[Ilyas]

220Volt:
Je l'ai fait en VC++, mais je pense que les mécanismes de libération de la mémoire sont les mêmes ?

Non, en C++ vous devez spécifier un destructeur virtuel pour supprimer correctement un objet via delete.

Mais votre exemple fonctionnera correctement, car vous pouvez spécifier le destructeur virtuel uniquement pour la classe de base.

[[Supprimé]]

Je vais essayer de présenter l'idée d'une manière légèrement différente :

Étant donné :

• Classe 1 - elle occupe 100 octets en mémoire.
• Classe #2 - elle est une descendante de la classe #1 et occupe 200 octets en mémoire.
• Pointeur vers la classe #1.

Actions :

• Ecrire dans le pointeur l'adresse de la section de mémoire où se trouve une instance de la classe #2 (call new)
• Libère la zone de soudure en passant la fonction de suppression à l'adresse stockée dans le pointeur.

P.S. : la figure montre le modèle de mémoire )

[[Supprimé]]

J'ai des doutes car le pointeur sur la classe numéro 1, mais en fait la classe numéro 2 est en mémoire. Cela compte dans le cas des destructeurs, et je me suis donc demandé s'il n'y avait pas un problème ici aussi. Je pense que dans cette situation, la libération correcte de la mémoire ne peut se produire que s'il y a des étiquettes en mémoire (comme un char avec un terminateur nul) ou quelque chose comme ça, c'est pourquoi j'ai posé la question de l'allocation de mémoire.

[Mykola Demko]

220Volt:
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 :

class CFoo
  {
public:
                     CFoo() { Print(__FUNCSIG__); }
                    ~CFoo() { Print(__FUNCSIG__); }
  };
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
class CBar : public CFoo
  {
public:
                     CBar() { Print(__FUNCSIG__); }
                    ~CBar() { Print(__FUNCSIG__); }
  };
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
void OnStart()
  {
   CFoo *f=new CBar();

   delete f;
  }
//+------------------------------------------------------------------+

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.

[[Supprimé]]

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, puis on me dit de libérer la mémoire, qui est pointée par un pointeur représentant un objet de taille 100 octets.

[Ilyas]

220Volt:
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 suppose que votre question est liée à la façon dont le pool de mémoire fonctionne.
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.

[Mykola Demko]

220Volt:
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 suppose que vous n'avez pas analysé mon échantillon. Sinon, vous n'auriez pas posé de telles questions.

[[Supprimé]]

J'étais en train de réfléchir, je me suis souvenu que l'on peut allouer de la mémoire pour un tableau d'int par exemple et ensuite les supprimer tous, malgré le fait qu'un int soit petit, probablement la même chose avec les classes. Merci pour les réponses.

[[Supprimé]]

mql5:
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.

C'est à peu près tout, merci.