Erreurs, bugs, questions - page 2747
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
Mon débogueur refuse de fonctionner dans l'un de mes projets. En outre, son comportement est difficile à prévoir. Parfois, il refuse tout simplement d'entrer dans les points d'arrêt. Il refuse également d'entrer dans certaines fonctions. Au début, je pensais que la raison était les mises à jour (peut-être que quelque chose s'est mal passé avec le débogage). Mais dans d'autres programmes plus simples, tout semble fonctionner. Je ne l'ai pas beaucoup consulté, cependant, car je travaille sur mon projet principal. Il est assez complexe et comprend 15 modules uniquement de ma propre conception (je n'ai pas compté le nombre de modules standard). Le module principal contient jusqu'à 2000 lignes. Je pensais que c'était peut-être une question de complexité du projet... De même, à certains endroits, j'utilise des macros pour les extraits de code répétitifs. J'utilise également des éléments standard de l'interface utilisateur, tels que CAppDialog, CCheckGroup, CComboBox, CButton etc. que j'ai réécrits pour la fonctionnalité de mon programme. Peut-être que le débogage ne fonctionne pas à cause d'eux... Par exemple, la méthode CCheckGroup::itemCheckState(const string item) que j'ai spécifiquement écrite ne débogue pas. La méthode trouve l'élément de la case à cocher et vérifie s'il est sélectionné (son état) :
Voici le type d'interface utilisateur que j'ai obtenu :
Certains des éléments de l'interface utilisateur sont temporairement classés. Et voici une branche où j'ai décrit comment j'ai remplacé les méthodes Show() et Hide() de l'élément CAppDialog: https://www.mql5.com/ru/forum/338301. Le compilateur s'est plaint à ce moment-là et une erreur critique s'est produite.
Au final, le projet se compile normalement, le compilateur ne génère aucune erreur. Mais le débogage échoue et ne montre pas l'exécution de certains fragments de code, fonctions, méthodes, etc.
D'après ce que je comprends, il peut y avoir plusieurs raisons à cela.
Informations sur la construction et le système :
https://www.mql5.com/ru/forum/1111/page2746#comment_16481481
Dans la méthode CCheckGroup::itemCheckState (dans laquelle le débogueur ne peut pas entrer) je mets quelque chose comme ceci :
Et j'ai obtenu le message suivant :
2020.05.21 13:20:44.229 CCheckGroup::itemCheckState item : 39 state : 32
https://www.mql5.com/ru/forum/1111/page2746#comment_16481481
Si le débogueur ne fonctionne pas correctement, le projet peut être retardé pendant une longue période. J'aimerais que les développeurs prêtent attention à ce bug très probablement lié au débogueur.
Il y a beaucoup de texte, je ne l'ai pas lu en entier.
Mais si quelque chose fonctionne dans la version debug et ne fonctionne pas dans la version release, ou vice versa, vérifiez si toutes les variables et tous les champs, en particulier dans la classe/structure, ont été initialisés.
#define GETCURRENTTICK GetCurrentTick1(Tick)#define GETCURRENTTICK GetCurrentTick2(Tick, !i)#define GETCURRENTTICK GetCurrentTick3(Tick)Au sujet de la gratuité des fonctions de SymbolInfo.
si la méthode est inline, alors ce n'est pas le problème du débogueur, mais celui du compilateur pour le mode débogage.
Exactement, le projet s'est avéré déborder de macros, les miennes et celles des modules standards. C'est peut-être pour cela que le débogueur ne parvient pas toujours à faire correspondre les commandes du fichier de débogage *.ex5 avec les lignes du fichier source *.mq5 et des autres modules...
Les fonctions de SymbolInfo sont gratuites.
il s'agit donc du coût de la fonction elle-même, et non du coût du passage de la chaîne par valeur, et non par référence !
Votre version avec le cache est une sacrée solution, si l'exécution de cette fonction prend un pourcentage significatif du temps d'exécution de l'EA (ce que je ne crois pas vraiment).
Exactement, le projet s'est avéré déborder de macros, les miennes et celles des modules standards. C'est peut-être pour cela que le débogueur ne parvient pas toujours à faire correspondre les commandes du fichier de débogage *.ex5 avec les lignes du fichier source *.mq5 et des autres modules...
est le coût de la fonction elle-même, et non le coût du passage de la chaîne par valeur, et non par référence !
C'est ce que j'essayais de dire au départ.
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie
Erreurs, bugs, questions
fxsaber, 2020.05.20 13:24
C'est mieux d'avoir
Dans l'optimiseur, ces fonctions sont appelées des dizaines de milliards de fois.
De plus, votre variante avec le cache est une sacrée solution, si l'exécution de cette fonction prend un pourcentage significatif du temps d'exécution d'une EA (ce que je ne crois pas vraiment).
À un certain stade, non seulement la partie relative du temps pris devient importante, mais aussi la partie absolue.
C'est beaucoup de texte, je n'ai pas tout lu.
Mais si quelque chose fonctionne dans la version debug et ne fonctionne pas dans la version release, ou vice versa, alors vérifiez si toutes les variables et tous les champs, en particulier dans la classe/structure, ont été initialisés.
Les données qui devaient être initialisées, je les ai initialisées. Et si des données aléatoires s'y trouvent, cela provoquera une erreur dans le programme lui-même (par exemple, Array out of range ou Invalid pointer). Au moins, cela n'affectera pas le fonctionnement du débogueur. Et cela aide à trouver de tels bugs.