MQL5 Le compilateur ne fait pas la distinction entre une classe et un pointeur vers celle-ci - page 6
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
Couler implicitement ce pointeur vers un objet
Le nom correct est "déréférencement implicite de pointeur".
Je soutiens la proposition d'interdire, de ne laisser le déréférencement implicite que lorsqu'il s'agit de se référer à un membre d'une classe, par exemple :
Ici, c'est l'inverse - un pointeur 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 égal à l'appel à toute autre méthode d'objet), cela conduit à une ambiguïté dans la compréhension 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 : +-<>[].
En résumé, la conclusion est la suivante : lorsque vous appliquez à un pointeur des opérateurs autorisés pour les pointeurs en C++, interdisez le casting implicite de ce pointeur vers un objet. En conséquence, l'exemple ci-dessus aurait une erreur de compilation.
Oui, je vois. En utilisant ces exemples simples, je voulais montrer à tous les sceptiques que le pointeur et l'objet sont des entités différentes et qu'il ne faut pas les confondre.
Et cette circonstance exige au moins un certain style d'écriture du code pour ne pas faire d'erreur et construire un code qui compilera et même passera le test mais échouera en conditions réelles, voire pire s'il a été écrit pour la vente. Ce ne sera pas une tâche facile de trouver un point d'erreur dans le code où tout est si "implicite".
Trouver un lieu d'erreur dans un code où tout est si "implicite" sera un véritable défi.
Il serait préférable que les développeurs laissent les choses telles qu'elles sont. S'ils recommencent à changer le langage, un tas de programmes cessent de se compiler, ou pire, cessent de fonctionner comme prévu, il y aura un tollé dans le monde entier.
De mon point de vue, les auto-objets dans µl sont un rudiment, des sous-pointeurs avec des fonctions limitées (pointeur constant avec auto-effacement), et ils n'ont généralement pas besoin d'être utilisés du tout (sauf pour le garbage collector).
Il serait préférable que les développeurs laissent les choses telles qu'elles sont. S'ils commencent à changer à nouveau le langage, un tas de programmes cessent de se compiler, ou pire encore, cessent de fonctionner comme prévu, il y aura un tollé dans le monde entier.
Les changements ici sont minimes. Il s'agit juste d'ajouter des règles de compilation à
afin qu'il ne permette pas de compiler la merde qui est maintenant considérée comme bonne.
Pour qu'il ne vous laisse pas compiler le genre d'hérésie qui est maintenant considérée comme bonne.
comme A a = nouveau A ? Ou quoi exactement ?) est maintenant utilisé par tout le monde, donc il n'a aucun effet.
Mais si vous écrivez A a, *b = a ; vous obtenez une erreur d'exécution, dans ce cas le compilateur doit explicitement générer l'avertissement "utilisation probable d'une variable 'b' non initialisée" comme il le fait avec tous les autres types. Si ce n'est pas une erreur de compilation du tout. Mais pas à cause de l'affectation en soi, mais à cause de l'utilisation d'une fonction surchargée sur une variable non initialisée qui provoque une erreur d'exécution, bien sûr. Il s'agit en réalité d'un bogue et il semble être lié à une optimisation excessive du code.
Et en général, il n'y a pas d'hérésie à assigner auto à dino et vice versa, ce sont des fonctionnalités qui peuvent être utiles.
Mais je supprimerais complètement la copie implicite d'objets. Bien que ce soit un standard en C++. C'est en fait la raison de tous ces problèmes.comme A a = nouveau A ? Ou quoi exactement ?)
Cela va sans dire. Il y a une fuite de mémoire ici.
Mais en général, il n'y a pas d'hérésie à assigner auto à dino et vice versa, ce sont des caractéristiques qui peuvent être utiles.
Oui, que ce soit. Mais explicite. Et cela ne sera pas fait par erreur, mais parce que je dois le faire.
Eh bien, c'est un fait. Il y a une fuite de mémoire ici.
Cette fuite est purement de votre faute. Si vous avez un objet à gauche, pourquoi écrire une telle construction ?
Mais la situation inverse, lorsque vous assignez quelque chose à un pointeur et qu'il est soudainement déréférencé, est une erreur non évidente.
Tout est mélangé ici, aussi bien les mouches que les escalopes. Je parle de la discussion sur le sujet.
Si vous avez un objet à gauche, pourquoi écrire une telle construction ?
Le facteur humain ! Le compilateur doit les réduire au minimum.
Le facteur humain ! Le compilateur doit les réduire au minimum.