Caractéristiques du langage mql5, subtilités et techniques - page 122
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
Résultat
La troisième variante (switch) est régulièrement plus lente que la deuxième (pointeurs de fonction). Quelle en est la raison ?
ZS Lentement. Le troisième commutateur est plus rapide que le deuxième. Tout va bien.
Ainsi, si vous avez un tableau immuable de pointeurs vers des fonctions, il sera plus rapide si vous le remplacez par switch.
Ainsi, si nous avons un tableau immuable de pointeurs vers des fonctions, il est plus rapide de le remplacer par switch.
Dans ce cas, c'est logique, car le tableau a été rempli dynamiquement, ce qui implique des contrôles constants de la validité des pointeurs.
Mais si MQL supportait l'initialisation des tableaux par des pointeurs constants, ce serait probablement la même chose.
p.s. Votre code n'est pas du tout lisible. Bien sûr, je comprends que vous trouviez toutes ces subtilités avec les macros commodes, puisque vous les avez écrites vous-même, donc vous savez ce qu'elles font. Mais pour un lecteur externe, c'est juste un puzzle. Je pense qu'il est peu probable que vous compreniez vous-même ce que vous avez fait ici en six mois... Faites au moins un commentaire ou quelque chose...
p.s. Votre code est complètement illisible. Bien sûr, je comprends que vous soyez à l'aise avec tous ces artifices avec les macros, parce que vous les avez vous-même écrites, donc vous savez ce qu'elles font. Mais pour un lecteur externe - c'est juste un puzzle. Je pense qu'il est peu probable que vous compreniez vous-même ce que vous avez fait là dans six mois... Faites au moins un commentaire ou quelque chose...
Sinon, vous seriez dans le pétrin. De plus, j'expérimentais le nombre de transitions. Sans les macros, cela aurait été difficile. À propos des commentaires supplémentaires - j'en tiendrai compte à l'avenir.
Sinon, ça aurait été le bordel. De plus, j'ai expérimenté avec le nombre de transitions. Sans les macros, cela aurait été difficile. À propos des commentaires supplémentaires - j'en tiendrai compte à l'avenir.
Parfois, il est beaucoup plus facile de démonter un écheveau compréhensible que de commencer à démonter un puzzle compact et d'abandonner immédiatement cette activité inutile.
Il est parfois plus facile de démêler un texte compréhensible que de commencer à décortiquer un puzzle compact et d'abandonner immédiatement cette tâche inutile.
En plus de ce qui précède, l'une des causes les plus courantes d'exécutions non concordantes dans le testeur est une initialisation défectueuse ou un manque d'initialisation.
Si l'initialisation des variables manquantes est simple, celle des tableaux est un peu plus compliquée. Le plus souvent, c'est la découverte de situations où le nombre d'éléments du tableau augmente qui peut indiquer un endroit problématique.
Afin d'éviter ces problèmes potentiels, vous pouvez insérer ces chaînes au début du conseiller expert.
Si la situation est détectée, les informations détaillées seront écrites dans le journal et l'exécution sera arrêtée.
SZZ Exemple d' application.
Je comprends, j'utilise souvent cette méthode moi-même, mais qu'en est-il de l'initialisation ? Comment peut-il être invalide ?
Par exemple, ArrayResize et ArrayInitialize sont confondus. Ou, par exemple, l'indicateur effectue ArrayInitialize du tampon à OnInit, pensant par erreur que le tampon est initialisé.
Par exemple, ArrayResize et ArrayInitialize sont confondus.
C'est une erreur très enfantine. Cela vaut-il la peine de faire un tel effort pour la trouver ?
C'est une erreur enfantine. Ça vaut le coup de la chercher ?
Trouver une erreur demande un effort. Surtout lorsque le code est volumineux et n'est pas le vôtre.