Questions sur la POO dans MQL5 - page 4

Nouveau commentaire
 
Dmitry Fedoseev:
Le pointeur peut également être transmis par non-référence - sans &.
Oui, vous pouvez. Mais si nous passons un pointeur sans &, un nouveau pointeur est créé sur la pile auquel la valeur passée est assignée. De plus, si nous allouons de la mémoire par ce pointeur dans une fonction, c'est le pointeur créé sur la pile qui change, ce qui signifie que nous avons une fuite de mémoire lors du déroulement de la pile. Bien sûr, ce n'est pas bien de faire ça, mais si on veut...
 
Vladimir Simakov:
Si les destructeurs sont appelés de cette manière, le pointeur créé sur la pile sera modifié et, par conséquent, nous obtenons des fuites de mémoire lorsque la pile est "déroulée". Bien sûr, ce n'est pas bien de faire ça, mais si on veut...

le comportement des pointeurs vers les classes dans MQL n'est pas prévisible, un des admins a écrit une fois que toutes les classes sont créées dans la mémoire globale (allocation de mémoire), vous écrivez que les pointeurs vers les classes dans la portée locale sont créés dans la pile (imho, il devrait en être ainsi !)

Bien que je puisse être confondu par quelque chose, je vais peut-être vérifier - en théorie, ce n'est pas difficile à vérifier, il suffit d'enregistrer Print() dans le destructeur de la classe de test, les destructeurs doivent être appelés automatiquement lorsqu'ils quittent la portée locale....

 
Vladimir Simakov:
Oui, ils le peuvent. Ce n'est que si nous passons un pointeur sans &, un nouveau pointeur est créé sur la pile auquel la valeur passée est assignée. Et si on alloue de la mémoire par ce pointeur dans une fonction, c'est le pointeur créé sur la pile qui change, donc on a une fuite de mémoire quand on déroule la pile. Bien sûr, ce n'est pas bien de faire ça, mais si on veut...

Il n'y aura pas de fuites. Parce que personne n'alloue quoi que ce soit à ce pointeur dans la fonction.

 
Igor Makanu:

le comportement des pointeurs vers les classes dans MQL n'est pas prévisible, un des admins a écrit une fois que toutes les classes sont créées dans la mémoire globale (allocation de mémoire), vous écrivez que les pointeurs vers les classes dans la portée locale sont créés dans la pile (imho, il devrait en être ainsi !)

Bien que je puisse être confondu par quelque chose, je vais peut-être vérifier - en théorie, ce n'est pas difficile à vérifier, il suffit d'enregistrer Print() dans le destructeur de la classe de test, les destructeurs doivent être appelés automatiquement lorsqu'ils quittent la portée locale....

Si la mémoire est allouée dynamiquement (new), elle est allouée dans le tas et si vous créez un objet sur la pile (CObj obj ;), la mémoire lui est allouée sur la pile également.

 
Dmitry Fedoseev:

Il n'y aura pas de fuites. Parce que personne n'alloue quoi que ce soit à ce pointeur dans la fonction.

void CreateLabel(CChartObjectLabel *l,string name,int y)
  {
   l=new CChartObjectLabel;
   l.Create(0,name,ChartWindowFind(),0,y);
   l.Color(clrYellow);
   l.FontSize(14);
   l.Description(name);
  }

C'est une fuite classique. Le pointeur créé sur la pile et initialisé lors de sa création avec la valeur passée dans la fonction s'est vu attribuer une nouvelle valeur et est devenu le pointeur d'un nouvel objet. Après cela, le pointeur a été tué en toute sécurité lorsque la pile est dépliée. C'est exactement ce que nous devions prouver. C'est exactement là où il devrait être :

void CreateLabel(CChartObjectLabel* &l,string name,int y)
 
Vladimir Simakov:

Si la mémoire est allouée dynamiquement (new), elle est allouée dans le tas, et si vous créez un objet sur la pile (CObj obj ;), la mémoire lui est également allouée sur la pile.

Dans mql il n'y a pas de telle chose - (CObj obj ;).

 
Vladimir Simakov:

Une fuite classique. Un pointeur créé sur la pile et initialisé à la création avec la valeur passée dans la fonction s'est vu attribuer une nouvelle valeur et est devenu un pointeur vers un nouvel objet. Après cela, le pointeur a été tué en toute sécurité lorsque la pile a été dépliée. C'est exactement ce que nous devions prouver. C'est exactement là où il devrait être :

Ne confondez pas le don de Dieu avec un œuf. Raison de plus pour écrire un code idiot pour prouver une affirmation erronée...

 
Dmitry Fedoseev:

Pas de telle chose dans mql - (CObj obj ;)

Allez ! Je l'utilise tout le temps.
 
Vladimir Simakov: 
void CreateLabel(CChartObjectLabel *l,string name,int y)
  {
   l=new CChartObjectLabel;
   l.Create(0,name,ChartWindowFind(),0,y);
   l.Color(clrYellow);
   l.FontSize(14);
   l.Description(name);
  }

Une fuite classique. Un pointeur créé sur la pile et initialisé à la création avec la valeur passée dans la fonction s'est vu attribuer une nouvelle valeur et est devenu un pointeur vers un nouvel objet. Après cela, le pointeur a été tué en toute sécurité lorsque la pile a été dépliée. C'est exactement ce que nous devions prouver. C'est exactement là où il devrait être :

Pourquoi réassigner intentionnellement un pointeur passé à une fonction? Bien sûr, il y aura une fuite. Mais il ne s'agit pas d'une "fuite classique", mais d'une erreur classique de manipulation d'un pointeur sur un objet.

Il n'est pas nécessaire de créer un nouvel objet ici, mais de manipuler l'objet externe dont le pointeur a été passé dans la fonction.

 
Vladimir Simakov:
Allez ! Je l'utilise tout le temps.

Où ? Où et comment ?

1234567891011...96
Nouveau commentaire
Raison: