Erreurs, bugs, questions - page 493
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
Je ne discute pas.
mais de cette façon
il y a un arrondi de toute façon, doit-il le faire ?
Les développeurs.
J'ai accidentellement bouclé le traitement des ticks dans Expert Advisor, après quoi une erreur critique de dépassement de pile est apparue.
Le problème est qu'il n'y a aucune information spécifique dans le message sur ce qui s'est passé et où exactement.
Je suggère de clarifier le texte de ce message, si possible vous voulez attraper de tels problèmes (comme l'appel d'une méthode de classe à partir d'une méthode appelée) à l'étape de la compilation.
La raison pour laquelle iCustom() attribue des valeurs arbitraires à ces cellules tampons, qui en réalité n'étaient remplies de rien, n'est pas claire pour moi, de même que la raison pour laquelle cela ne peut être évité d'aucune manière.
Je suppose que cela a quelque chose à voir avec l'allocation de mémoire pour le tableau de données correspondant du tampon indicateur.
Une telle opération de iCustom(), alors qu'il est impossible de déterminer l'origine et la véracité des données, me semble inadmissible et crée des risques supplémentaires pour l'utilisateur.
Si iCustom() attribue de toute façon des valeurs arbitraires et incohérentes avec les valeurs réelles aux cellules tampons,
pourquoi n'assigne-t-il pas des valeurs égales à Empty_Value à ces cellules comme cela est implémenté dans MT4 ?
Au moins, leur statut serait clair.
Les développeurs.
..........., si possible voulez attraper des problèmes comme celui-ci (comme l'appel d'une méthode de classe à partir d'une méthode appelée) au moment de la compilation.
Je suis contre. Cela rendrait le compilateur excessivement compliqué et donc moins fiable.
C'est au programmeur de repérer les récursions incorrectes.
Mais je voudrais que le message d'erreur contienne le nom de la fonction qui a fait déborder la pile.
Personne d'autre que l'auteur ne peut décider avec quelles valeurs tampons inutilisées il convient de les remplir. Vous dites Empty_Value, mais moi, par exemple, je veux que ce soit 0, ou autre chose. Quelle que soit la valeur que vous voulez, initialisez-le avec elle.
C'est correct et logique. Mais le problème est que les cellules tampons que l'utilisateur n'a pas remplies avec quoi que ce soit ( !), la fonction iCustom() les remplit périodiquement avec des déchets arbitraires à sa discrétion. Est-ce censé être comme ça ?
Je suis contre. Cela rendrait le compilateur exorbitant de complexité et donc moins fiable.
C'est au programmeur de repérer les récursions incorrectes.
Mais je voudrais que le message d'erreur contienne le nom de la fonction qui a fait déborder la pile.
Oui, nous faisons exprès de ne pas compliquer le moteur de travail (il s'agit d'un moteur 32/64 natif après tout) avec des méta-informations.
La récursion est généralement facile à attraper - elle dépend directement de la taille des variables locales, et il y a très peu de ces endroits dans un programme.
C'est correct et logique. Mais le problème est que les cellules tampons, que l'utilisateur n'a pas remplies avec quoi que ce soit ( !), la fonction iCustom() les remplit avec des déchets aléatoires à sa discrétion. Est-ce que c'est censé être comme ça ?
Si l'indicateur personnalisé ne remplit pas correctement son tampon, cet indicateur personnalisé est coupable.
Et si cet indicateur personnalisé envoie ses résultats par le biais d'iCustom, il est doublement coupable, car il induit les utilisateurs en erreur.
Si un indicateur personnalisé ne remplit pas correctement son tampon, cela signifie que cet indicateur personnalisé est coupable.
Et si cet indicateur personnalisé donne ses résultats par le biais d'iCustom, il est doublement coupable, car il induit les utilisateurs en erreur.
Si un indicateur personnalisé ne remplit pas correctement son tampon, c'est cet indicateur personnalisé qui est à blâmer.
Et si cet indicateur personnalisé envoie ses résultats par le biais d'iCustom, il est doublement coupable, car il induit les utilisateurs en erreur.
Je ne comprends toujours pas, qu'est-ce qui vous empêche de rendre le programme non seulement efficace, mais aussi pratique ? Si je me souviens bien, le raisonnement pour l'absence d'initialisation intégrée des tampons d'indicateurs dans 5 est d'optimiser la vitesse. Dans ce cas, le développeur de l'indicateur doit coder lui-même les chaînes d'initialisation ("zeros"), qui étaient auparavant effectuées par le noyau. Ainsi, l'efficacité résultante ne semble pas s'améliorer, et la convivialité en souffre. Mais puisqu'il a été décidé de procéder de cette façon pour une raison quelconque, pourquoi ne pas le rendre facultatif ? C'est-à-dire que nous pourrions introduire une #propriété supplémentaire, spécifiant si les tampons doivent être initialisés automatiquement ou non.
Pour résumer, je vais répéter l'idée que j'ai déjà exprimée une fois : la tâche de la plate-forme, qui est MT, est de protéger autant que possible l'utilisateur (le programmeur) d'éventuelles "erreurs".
C'est correct et logique. Mais le problème est que les cellules tampons que l'utilisateur n'a pas remplies ( !) avec quoi que ce soit, iCustom() les remplit périodiquement avec des déchets arbitraires à sa propre discrétion. Est-ce censé être comme ça ?
En fait, c'est une règle commune : l'initialisation des tableaux est à la discrétion de l'utilisateur. Un tableau non initialisé contient des valeurs aléatoires de la mémoire qui lui est allouée. L'utilisateur peut avoir une bonne raison de ne pas initialiser le tableau inutilement (pour gagner du temps, par exemple). Je gagne parfois du temps de cette façon lorsque je suis sûr de ne pas avoir à lire et à "manger" ces bêtises avant d'avoir obtenu les véritables informations.
Je ne vois aucune malice du côté de MQ. Je m'opposerai plutôt à ce qu'ils commencent à ralentir mes programmes de manière "prophylactique".