Effacement forcé des tableaux dans MT5 ? - page 2
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
Bien sûr que oui.
Tout programmeur qui se respecte et respecte ses programmes ne laissera pas les choses suivre leur cours. 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 des valeurs en dehors du tableau, mais s'il le fait "à peu près", il ne pense pas à un tel contrôle, et "l'essentiel est que ça marche, mais comment ça marche - 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 des vérifications et un 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...".
Nikolaï, ne vous inquiétez pas pour MQL4, tout y est parfait. Le topicstarter remplit les tableaux comme il le souhaite. Tout.
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...".
C'est dommage !
Eh bien, Petr, grâce à la rigueur de MQL5, vous avez une chance de remettre le code dans un ordre relatif et de vider le tas de déchets.
Vous pouvez même essayer de compiler le code corrigé avec #property strict vers MQL4 et peut-être qu'il fonctionnera plus rapidement sur MT4.
Merde !
Eh bien, Peter, grâce à la rigueur de MQL5, nous avons une chance de mettre le code dans un ordre relatif et de vider les piles de déchets.
Vous pouvez même essayer de compiler le code corrigé avec #property strict dans MQL4 et, peut-être, il fonctionnera beaucoup plus rapidement dans MT4
C'est ainsi que, a priori, vous avez décidé que mon code est plein de déchets.
Je m'explique : le noyau est rempli par étapes, en plusieurs fois. Si lors de la déclaration d'un tableau dans MT5, il y a des déchets dedans (ce que je ne savais pas), alors lors des premières étapes de la construction du noyau dans les fonctions, il y a un débordement en dehors du tableau, parce qu'au lieu de pointeurs vers des variables, je me réfère à une cellule du noyau par une autre. S'il contient zéro, c'est OK, et il obtient la bonne valeur lors de la deuxième exécution, mais s'il contient des déchets, une erreur critique se produit.
Est-ce que c'est clair pour vous ?
Peter, je ne sais pas ce que tu veux dire.
Exactement, vous ne comprenez pas. Vous comparez mes tâches aux vôtres...
Je n'ai pas de débordements. Considérez les spécificités de ma technologie (vous avez oublié que vous l'ignorez). Si vous utilisez une autre cellule du tableau comme pointeur vers une cellule, et qu'il y a des déchets dedans, alors vous êtes hors du tableau. Le problème est que pour que la cellule à laquelle vous faites référence obtienne la valeur correcte, vous devez passer au deuxième tour de la construction du noyau. Et au deuxième tour, la valeur sera correcte. Mais on n'arrive pas au deuxième tour à cause d'une erreur critique.
Tout cela est dû à la présence de déchets dans le tableau déclaré.
Nous devons donc inventer des mécanismes pour effacer le tableau bidimensionnel (noyau) au stade de la première définition de la taille (construction de la zone régulière) et au stade du deuxième redimensionnement du noyau, lors de la construction de la zone utilisateur.
Exactement, vous ne comprenez pas. Comparé, mes tâches et les vôtres...
Allez-y et créez un monologue - 10 postes de plus à la suite.
C'est ainsi que, a priori, vous avez décidé que mon code est plein de déchets.
Je m'explique : le noyau est rempli par étapes, en plusieurs fois. Si lors de la déclaration d'un tableau dans MT5, il y a des déchets dedans (ce que je ne savais pas), alors lors des premières étapes de la construction du noyau dans les fonctions, il y a un débordement en dehors du tableau, parce qu'au lieu de pointeurs vers des variables, je me réfère à une cellule du noyau par une autre. S'il contient zéro, c'est OK, et il obtient la bonne valeur lors de la deuxième exécution, mais s'il contient des déchets, une erreur critique se produit.
Est-ce que c'est clair pour vous ?
Ce n'est pasdu tout comme ça. Ce ne sont pas les déchets qui sont à blâmer, mais l'absence de #property strict dans mql4. Sans cela, vous obtenez 0 au lieu d'un dépassement de tableau, et dans mql5 c'est déjà une erreur critique. Il est probablement préférable de vérifier la longueur du tableau plutôt que le contenu d'un index de tableau inexistant.
Retag n'est pas du tout comme ça. Ce ne sont pas les déchets qui sont à blâmer, c'est l'absence de #property strict dans mql4. Sans cette astuce, vous obtenez 0 au lieu d'un dépassement de tableau, et dans mql5 déjà une erreur critique. Il est probablement préférable de vérifier la longueur du tableau plutôt que le contenu d'un index de tableau inexistant.
Le hors-limite se produit parce qu'il y a des déchets dans la cellule indicatrice.
Par exemple :
Initiale :
G_CORE[Object][Kanvas] = -123423452345 ; (déchets)
G_CORE[Window][His_canvas]= -452345 ; (déchets)
//-----------------------------------------------------------------
Le résultat est en dehors du tableau.
Je le répète. Certaines cellules ont des valeurs nulles dans MT4 et sont remplies au deuxième tour lors de la première étape du remplissage du noyau.
Dans MT5, en raison de déchets dans les cellules, il y a une erreur critique au premier tour.
Si les cellules du tableau contenaient des zéros, il n'y aurait pas d'erreur et le noyau se remplirait séquentiellement (comme il se doit).
Voici un exemple plus précis :
Le premier tour de la construction du noyau. Dans l'une des fonctions :
Le hors-limite se produit parce qu'il y a des déchets dans la cellule indicatrice.
Par exemple :
Initiale :
G_CORE[Object][Kanvas] = -123423452345 ; (déchets)
G_CORE[Window][His_canvas]= -452345 ; (déchets)
//-----------------------------------------------------------------
Le résultat est en dehors du tableau.
Je le répète. Certaines cellules ont des valeurs nulles dans MT4 et sont remplies au second tour lors de la première étape du remplissage du noyau.
Dans MT5, en raison de déchets dans les cellules, il y a une erreur critique au premier tour.
S'il y avait des zéros dans les cellules du tableau, il n'y aurait pas d'erreur et le noyau serait rempli séquentiellement (comme il se doit).
La non-initialisation du tableau est entièrement la faute du kodopistael. Recherchez l'erreur dans votre propre environnement. Reconstruisez votre algorithme.