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
Le pointeur peut également être transmis par non-référence - sans &.
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....
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.
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.
Il n'y aura pas de fuites. Parce que personne n'alloue quoi que ce soit à ce pointeur dans la fonction.
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 :
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 ;).
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...
Pas de telle chose dans mql - (CObj obj ;)
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.
Allez ! Je l'utilise tout le temps.
Où ? Où et comment ?