MQL5 Le compilateur ne fait pas la distinction entre une classe et un pointeur vers celle-ci - page 5
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
Il n'y a aucun moyen de le déclencher. C'est une pure fuite de mémoire.
Faites en sorte qu'il puisse être invoqué.
Au fait, messieurs les développeurs, nous ferions mieux de réparer ça. Après tout, new renvoie un pointeur, alors ajoutez une vérification qu'à l'autre bout = aussi un pointeur, supprimez la conversion implicite (A) new A() ; comme je le comprends - c'est ce qui se passe.
Au fait, chers développeurs, je ferais mieux de réparer ça. Après tout, new renvoie réellement un pointeur, donc ajoutez une vérification que l'autre extrémité = également un pointeur, supprimez la conversion implicite (A) new A() ; comme je l'ai compris - c'est ce qui se passe.
Il y a un appel pour cet opérateur
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie
Le compilateur MQL5 ne fait pas la distinction entre une classe et un pointeur
fxsaber, 2019.01.10 06:36
Depuis quand sont-ils définis (question pour les développeurs) ?
Et comment fonctionnent-ils ? Le code compilé suivant semble délirant
Grosso modo, cela ressemble à ceci
L'appel à cet opérateur s'arrête là
Grosso modo, cela ressemble à ceci
Avant de faire des histoires, il serait bon de savoir qu'en MQL, les pointeurs ont toujours été implicitement convertis en objets (déréférencés), c'est pratique et tout le monde s'y est habitué. Au lieu d'un a()->b()->c()->d() difficile à lire, vous pouvez écrire dans le format habituel de la POO : a().b().c().d(), et faire moins de transformations inutiles en passant aux fonctions. Et maintenant, à cause du mécontentement de quelqu'un, vous changez tout ?
Avant d'en faire tout un plat, il serait bon de savoir qu'en MQL, les pointeurs ont toujours été convertis en objets implicitement (déréférencés), c'est pratique et tout le monde s'y est habitué. Au lieu d'un a()->b()->c()->d() difficile à lire, vous pouvez écrire dans le format habituel de la POO : a().b().c().d(), et faire moins de transformations inutiles en passant aux fonctions. Et maintenant, à cause du mécontentement de quelqu'un, vous changez tout ?
Ce n'est pas une question de casting. Tu n'y es pas allé.
Si nous sommes guidés par le prototype déclaré de MQL - C++.
En C++, l'opérateur new renvoie un pointeur, respectivement, si m_A est un tableau d'objets :
il y aurait une erreur de type ici.
C'est la ligne que le compilateur aurait sautée :
Mais cela provoquerait une fuite de mémoire.
Ce serait bien si MQL avait le même comportement.
Avant de commencer à faire des histoires à ce sujet, vous devez savoir que dans MQL, les pointeurs ont toujours été implicitement convertis en objets (déréférencés), c'est pratique et tout le monde s'y est habitué. Au lieu d'un a()->b()->c()->d() difficile à lire, vous pouvez écrire dans le format habituel de la POO : a().b().c().d(), et faire moins de transformations inutiles en passant aux fonctions. Et maintenant, à cause du mécontentement de quelqu'un, vous changez tout ?
Et si vous entrez dans les détails avec quelques exemples simples.
Par conséquent, nous avons
1. a' obtient une copie de l'objet créé, le pointeur vers le nouvel objet créé est perdu.
2) Qu'arrivera-t-il à 'a' si new ne parvient pas à créer/allouer un objet en mémoire ?
Le deuxième cas (au contraire)
1. après avoir quitté la fonction, l'objet 'b' doit être détruit comme un objet local.
à quoi fera référence le "a" alors ?
2. ou l'opérateur de copie fonctionnera-t-il toujours et 'b' sera copié par le pointeur 'a' ? et si 'a' n'a pas été défini auparavant ?
Le deuxième cas (au contraire)
Ici, c'est l'inverse - un pointeur a est implicitement casté vers un objet (déréférencé), puis operator= lui est appliqué. fxsaber l'a également mentionné hier.
Bien que logiquement cela ne contredise pas les règles MQL (puisque l'appel à operator= est équivalent à l'appel à toute autre méthode d'objet), cela conduit à une compréhension ambiguë de ce code et à des erreurs difficiles à trouver. Et cela ne concerne pas seulement l'opérateur= mais aussi == et !=, au moins. Peut-être qu'un tel casting devrait être interdit pour d'autres opérateurs également, car en C++ vous pouvez appliquer aux opérateurs : +-<>[].
Le verdict est le suivant : lorsque vous appliquez à un pointeur des opérateurs autorisés pour les pointeurs en C++, vous n'autorisez pas le transfert implicite de ce pointeur vers un objet. En conséquence, l'exemple ci-dessus entraînerait une erreur de compilation.