La raison du dépassement des limites est que les tableaux sont remplis de valeurs progressivement dans différentes fonctions, et dans ce processus, une cellule est accessible via une autre cellule. Certaines fonctions sont appelées deux fois et remplissent le tableau de manière séquentielle. Mais, s'il y a des déchets dans les cellules, il y a un dépassement au premier remplissage.
Je suppose que le problème peut être résolu en effaçant les tableaux à l'avance, mais cela constitue bien sûr un casse-tête supplémentaire. C'est dommage.
Il faut s'y habituer.
Je déclare toujours un tableau, je fixe la taille prévue, je le remplis de valeurs (je l'initialise). Il est souvent préférable d'initialiser avec une valeur non nulle - il est plus facile de trouver une erreur de cette façon.
Je n'ai jamais travaillé sérieusement avec MT5, et je suis en train d'y transférer un énorme projet en une seule fois. Naturellement, il y a des difficultés, l'une d'entre elles étant que le tableau est toujours hors de portée. Il s'avère que MT4 n'a pas eu ce problème, notamment parce que les tableaux n'ont pas dû être vidés à dessein après l'annonce. Mais dans MT5, c'est nécessaire. Ma technologie nécessite un remplissage progressif du noyau ainsi que des modifications de sa taille. La taille exacte de certains tableaux n'est pas connue à l'avance. En même temps, à cause du grand nombre de boucles sur les tableaux en cours de remplissage, tout serait en désordre. S'il n'y avait pas de déchets dans les cellules, tout fonctionnerait depuis longtemps.
C'est-à-dire qu'il y a d'une part des déchets dans les tableaux et d'autre part des erreurs critiques de dépassement. C'est comme une condition draconienne...
Je veux comprendre pourquoi ils ont dû supprimer l'effacement automatique des tableaux et réduire les variables déclarées à zéro, comme dans MT4 ?
Si nous pouvons tolérer les variables, nous serons confrontés au problème de la collecte constante de déchets dans les grands tableaux, et nous devrons les nettoyer non seulement lors de la déclaration, mais aussi lors du redimensionnement... Pourquoi ?
J'ai également rencontré des difficultés similaires au début.
A mon avis, les tableaux sont remplis d'une manière spécifique, cela devrait être pris en compte dans les boucles souvent.
Peter, je ne sais pas ce que tu veux dire ?
tous sur le mêmehttps://www.mql5.com/ru/forum/293630/page179#comment_10802823
maintenant c'est la faute de MQL5... ;)
- 2019.02.28
- www.mql5.com
tous sur le mêmehttps://www.mql5.com/ru/forum/293630/page179#comment_10802823
maintenant c'est la faute de MQL5... ;)
Oui. Je ne suis pas habitué à MQL4.
Nikolay, ne vous inquiétez pas pour MQL4, tout y est parfait. L'initiateur du sujet remplit les tableaux comme il le souhaite. C'est tout.
Eh bien, oui. Je ne suis pas habitué à MQL4.
Bien sûr que oui.
Tout programmeur qui se respecte et respecte ses programmes ne laissera pas passer les choses. En MQL4, si vous n'utilisez pas #property strict, vous pouvez faire référence à un tableau de taille 10 par l'index 20. Et rien ne se passera - le programme continuera à fonctionner, mais c'est au programmeur de décider ce qu'il faut utiliser ensuite. S'il est intelligent, il va certainement tout vérifier et contrôler, afin de ne pas obtenir de valeurs en dehors du tableau, mais s'il le fait "à l'arrache", il ne se soucie pas de ce contrôle, et "l'essentiel est que ça marche, mais comment ça va marcher d'une manière ou d'une autre...".
La majorité des utilisateurs, qui ne s'en sont pas souciés, se sont plaints de la "mauvaise, diabolique et compliquée MQL5", car elle ne leur permet pas de truquer leurs propres créations comme avant. Mais ceux qui, à l'origine, ont pensé et créé un code avec vérification et contrôle des données reçues, n'ont pas remarqué de différence dans la complexité des langages, et se demandent maintenant : "où est la complexité - c'est la même chose...".
Je n'ai jamais travaillé sérieusement avec MT5, et je suis en train d'y transférer un énorme projet en une seule fois.
Sérieuse différence dans les tableaux lors de la réécriture
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégies de trading
Caractéristiques du langage mql4, subtilités et astuces
fxsaber, 2019.02.12 13:12
Caractéristiques d'ArrayResize pour les tableaux multidimensionnelsvoid OnStart() { int Array[][2]; Print(ArrayResize(Array, 7)); // MQL5 - 7, MQL4 - 14 Print(ArraySize(Array)); // 14 }
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Vous acceptez la politique du site Web et les conditions d'utilisation
Je n'ai jamais travaillé sérieusement avec MT5, et je suis en train d'y transférer un énorme projet en une seule fois. Naturellement, il y a des difficultés, dont l'une est de sortir constamment du tableau. Il s'avère que MT4 n'a pas eu ce problème, notamment parce que les tableaux n'ont pas dû être vidés à dessein après l'annonce. Mais dans MT5, c'est nécessaire. Ma technologie nécessite un remplissage progressif du noyau ainsi que des modifications de sa taille. La taille exacte de certains tableaux n'est pas connue à l'avance. En même temps, à cause du grand nombre de boucles sur les tableaux en cours de remplissage, tout serait en désordre. S'il n'y avait pas de déchets dans les cellules, tout fonctionnerait depuis longtemps.
C'est-à-dire qu'il y a d'une part des déchets dans les tableaux et d'autre part des erreurs critiques de dépassement. C'est comme une condition draconienne...
Je veux comprendre pourquoi ils ont dû supprimer l'effacement automatique des tableaux et réduire les variables déclarées à zéro, comme dans MT4 ?
Si nous pouvons tolérer les variables, nous serons confrontés au problème de la collecte constante de déchets dans les grands tableaux, et nous devrons les nettoyer non seulement lors de la déclaration, mais aussi lors du redimensionnement... Pourquoi ?