Questions sur la POO dans MQL5 - page 8
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
ne pas écrire supprimer - tout fonctionnera correctement, ce péché (je veux dire superstition)) ) prendra le contrôle du terminal et marmonnera dans son journal "48 octets de mémoire perdue", puis "2 objets de type CX restants" et "objets non supprimés restants".
HH : dans le modèle d'indicateur, il n'y a pas de Deinit() - c'est ennuyeux.
Pourquoi ne pas créer un objet au lieu d'un pointeur ? Le sous-système du terminal le repérera et l'arrêtera si nécessaire.
Ça marchera sans supprimer, mais ça ne sert à rien. Mais le terminal prend-il en charge ce problème ? Il ne signale que les fuites de mémoire, mais ne consacre pas les mêmes objets.
Le terminal se chargera de supprimer les objets créés par new dans le cas où les pointeurs vers ceux-ci sont empilés dans un objet connu du terminal, par exemple ArrayObj, List, etc...
Pourquoi ne pas créer un objet au lieu d'un pointeur ? Le sous-système du terminal le repérera et l'arrêtera si nécessaire.
parce quehttps://www.mql5.com/ru/forum/85652/page7#comment_12329866
Le terminal se chargera de supprimer les objets créés par new dans le cas où les pointeurs vers ceux-ci sont empilés dans un objet connu du terminal, par exemple ArrayObj, List, etc....
pas toujours pratique la destruction non supervisée, mais je vais devoir vérifier, peut-être que je me trompe - j'utilise rarement CObject
parce quehttps://www.mql5.com/ru/forum/85652/page7#comment_12329866
Eh bien, il s'agit d'un cas très particulier et grotesquement simplifié, à mon avis. Créer un objet qui ne peut être modifié, de sorte que pour changer ses champs, il faut le clouer sur place et en créer un nouveau...
Et si nous devons modifier quelques champs d'objet et laisser les autres champs avec les informations nécessaires ? À mon avis, il vaut mieux s'occuper de l'interactivité et de la gérabilité de chaque objet (grâce à l'héritage), que de s'asseoir avec un fusil et de tirer des lapins à chaque éternuement.
Même si, pour être juste, il est parfois plus rapide de tuer et de créer un nouvel objet que de chercher l'objet souhaité parmi un grand nombre et de le modifier. A moins, bien sûr, qu'il y ait un lien direct avec...
Eh bien, il s'agit d'un cas très particulier et grotesquement simpliste, à mon avis. Créer un objet absolument immuable, de sorte que pour changer les valeurs de ses champs, il faut le clouer sur place et en faire naître un nouveau...
Et si nous devons modifier quelques champs d'objet et laisser les autres champs avec les informations nécessaires ? À mon avis, il vaut mieux s'occuper de l'interactivité et de la gérabilité de chaque objet (grâce à l'héritage), que de s'asseoir avec un fusil et de tirer sur des lapins à chaque éternuement.
Même si, pour être juste, il est parfois plus rapide de tuer et de créer un nouveau modèle, que de chercher le modèle requis parmi un grand nombre et de le modifier. A moins, bien sûr, que vous ayez un lien direct avec elle...
hmmm, vous êtes loin du compte.... oui, mais pas comme ça ))))
si c'est pratique, c'est comme ça que vous devez l'utiliser ! - et ces exemples du "premier manuel de c++" peuvent être tirés dans votre expérience toute votre vie.... à titre d'exemple, j'ai démonté une bonne partie du code de @fxsaber et je me suis forcé à utiliser #define autant que possible - les codes sont devenus non seulement plus courts, mais aussi plus lisibles et ont éliminé les fautes de frappe - est-ce qu'on enseigne cela dans les livres de C++ ? ;)
Même si, pour être juste, il est parfois plus rapide de tuer et de créer un nouveau modèle que de chercher le modèle requis parmi un grand nombre et de le modifier. Bien sûr, s'il n'y a pas d'adresse directe...
et à propos des bases du livre... Selon les "bonnes règles de reproduction" en programmation, ce qui suit est attendu : vous devez déclarer une variable et l'initialiser immédiatement (cela vous permet d'éviter les bugs lors du débogage), dans la POO le constructeur sert à ces fins - vous avez créé un objet et l'initialiser tout
si vous devez "tirer tout le code après un simple objet", vous aurez besoin d'une méthode pour réinitialiser tous les champs de la classe - pourquoi dupliquer cela ? - tuer/créer = résultat.... mais encore une fois, c'est une question de goût et de religion.
parce quehttps://www.mql5.com/ru/forum/85652/page7#comment_12329866
je ne suis pas toujours à l'aise avec la destruction non supervisée, mais il faudra vérifier, peut-être que je me trompe - j'utilise rarement CObject
Mais vous utilisez des listes. Et c'est la même chose là-bas. Eh bien, à moins que le drapeau de gestion de la mémoire FreeMode() ne soit pas remis à zéro pour la liste - dans ce cas, le terminal ne tracera pas - tout est entrepris par l'utilisateur. Mais cette situation est nécessaire pour pouvoir modifier, supprimer, trier et faire autre chose avec une copie de la liste - en fait, la liste est créée avec des pointeurs vers des objets, et si vous créez une nouvelle liste, une copie d'une des listes, et que vous commencez à modifier des objets dans la nouvelle liste (il y a des pointeurs vers des objets), alors dans la liste originale aussi les objets seront modifiés (parce que nous travaillons avec des pointeurs). C'est pour garder l'original et tripoter sa copie, alors vous devez laisser tomber le drapeau de la gestion de la mémoire pour une copie : FreeMode(false) - alors la copie devient une copie indépendante, et vous pouvez travailler en toute sécurité avec des objets dans celle-ci, sans affecter l'original. N'oubliez pas que lorsque vous dissociez la copie de la liste du sous-système terminal, c'est nous qui sommes responsables de la suppression des objets de la liste. Vous pouvez soit la suivre et la supprimer dans OnDeinit(), c'est-à-dire dans le cas le plus simple et si la liste de copies est connue auparavant, soit créer une liste d'objets, qui place toujours les listes nouvellement créées, non connues auparavant avec le drapeau de gestion manuelle de la mémoire. Ensuite, le terminal suivra cet objet liste et supprimera correctement les listes qui y sont empilées.
Le terminal prendra en charge la suppression des objets créés par new dans le cas où les pointeurs vers ceux-ci sont empilés dans un objet connu du terminal, par exemple ArrayObj, List, etc...
Alors il n'y aura pas non plus de message de fuite.
Alors il n'y aura pas non plus de rapport sur une fuite.
Oui, ça ne le sera pas. Parce qu'il n'y aura pas de fuite.
Si nous avons créé un nouvel objet quelque part et reçu un pointeur sur celui-ci, nous devons supprimer cet objet par le pointeur donné. Cela signifie que nous devons suivre le pointeur. À cette fin, les listes ou tableaux de pointeurs vers des objets, proposés dans SB, sont très bons. Mais vous pouvez également vous occuper du suivi et du contrôle des objets nouvellement créés. Mais, pour ma part, pourquoi écrire des tonnes de code si celui-ci est déjà fourni ?
alors ils doivent supprimer cet objet par ce pointeur.
Mais, pour ma part, pourquoi écrire des tonnes de code si celui-ci est déjà fourni ?
De quelles tonnes parlons-nous ? Tout ce que vous avez manqué est signalé par le terminal et l'endroit pour le supprimer est également connu - OnDeint() ..... Cette discussion se résume donc à une discussion sur un cheval sphérique dans le vide ? )))
hmm, vous devez vous moquer de moi..... comme ça, mais pas comme ça ))))
si c'est pratique, c'est comme ça que vous devez l'utiliser ! - et ces exemples du "premier manuel s++" peuvent être tirés de votre expérience toute votre vie.... à titre d'exemple, j'ai démonté une bonne partie du code de @fxsaber et je me suis forcé à utiliser #define autant que possible - les codes sont devenus non seulement plus courts, mais aussi plus lisibles et sans fautes de frappe - est-ce qu'on enseigne cela dans les livres de C++ ? ;)
Et à propos des bases du livre... Les bonnes règles de reproduction disent : proclamer une variable et l'initialiser immédiatement (cela vous permet d'éviter les bugs lors du débogage), en POO le constructeur sert à cette fin - vous avez créé un objet et tout initialiser
si vous devez "tirer tout le code après un simple objet", vous aurez besoin d'une méthode pour réinitialiser tous les champs de la classe - pourquoi dupliquer cela ? - tuer/créer = résultat.... mais encore une fois, c'est une question de goût et de religion.
Je ne parle pas de la réinitialisation complète d'un objet, mais partielle - lorsque quelques champs doivent être modifiés et que quelques dizaines d'autres contiennent toujours les informations dont vous avez besoin... Nous pouvons ou non vouloir changer les champs, mais nous avons besoin de méthodes pour le faire. Sauf si - encore une fois - nous parlons d'un objet simple avec un seul champ. S'il y en a deux ou plus, il se peut que vous deviez déjà en modifier un, en laissant les autres inchangés.
Mais peut-être que nous parlons de choses différentes ?