Erreurs, bugs, questions - page 2754
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
Ce qui confirme une fois de plus qu'il est inutile d'utiliser directement _Digits,_Point , _Period, _LastError, etc. (et même _Symbol peut être remplacé par NULL). En fait, ils doivent être déclarés comme const volatile.
Et vous, au contraire, vous proposez d'élargir cet éventail
Vous avez raison, mais ils sontpresque volatiles, à l'exception de l'indicateur IsStopped - il est 100% volatile, c'est-à-dire que toute lecture de IsStopped est une lecture de la mémoire à 100%.
Pour d'autres,presquevollatylе signifie que le compilateur PEUT mettre en cache la valeur d'une variable dans un registre lors du premier appel et utiliser la valeur en cache lors du prochain accès à cette variable, mais uniquement dans une fonction ou une branche d'appels, si elles sont inlined dans une fonction.
Ceci est possible (et nécessaire) parce que la modification des variables prédéfinies (sauf IsStopped) ne peut pas se faire à l'intérieur d'un point d'entrée MQL (fonction OnXXX).
En ce qui concerne le MODIFICATEURVARIABLE, disons qu'il est utilisé par des programmeurs constants pour des programmeurs.
Comme nous le savons, vous pouvez changer la constante d'une variable par le biais d'une conversion, on ne peut donc pas faire confiance au compilateur avec le modificateur const.
Si le compilateur voit que la variable n'a pas changé de valeur et qu'elle est initialisée comme une constante, il transformera une telle variable en une valeur immédiate (ImmediateValue) même sans le modificateur const
. Concernant _LastTick, nous discutons mais...
Il s'agit d'une structure, pas d'un simple type atomique, et elle peut être modifiée soudainement, à n'importe quel moment du programme MQL, y compris au moment de l'obtention de la valeur.
Il s'avère que pour traiter cette structure, il faut introduire un synchroniseur.
Nous travaillons constamment sur les performances, notamment en raison de ce rythme de publication élevé des builds.
Nous prévoyons de faire beaucoup d'efforts pour accélérer le code MQL.
En ce qui concerne _LastTick, nous discutons, mais...
Il s'agit d'une structure, et non d'un type atomique simple, et elle peut être modifiée soudainement, à n'importe quel moment du programme MQL, y compris au moment de l'obtention de la valeur.
Il s'avère que pour traiter cette structure, nous devons introduire un synchroniseur.
mais dans le testeur _LastTick ne peut pas changer à n'importe quel moment du programme MQL ?
si oui, alors donnez une telle solution seulement pour le testeur, où la vitesse des calculs est la plus importante.
mais dans le testeur _LastTick ne peut pas changer à n'importe quel moment du programme MQL ?
si oui, alors donnez une telle solution uniquement pour le testeur où la vitesse de calcul est la plus importante.
Alors, qu'est-ce qui vous empêche de demander une fois ce tick dans le handler OnTick et de travailler ensuite avec les données reçues ?
Les faibles qualifications des créateurs d'EE dont Market et Cloud sont chargés constituent un obstacle.
Donc, qu'est-ce qui empêche de demander le tick une fois dans le handler OnTick, et de continuer à travailler avec les données reçues ? Cela ne coûte pratiquement rien. Pourquoi le redemander 100 fois (comme dans les tests ci-dessus), en créant artificiellement des freins sur place ? Ainsi, on propose de résoudre le problème d'un code EA tordu en compliquant le travail interne de MT. Ou avez-vous des mesures normales ?
Les événements à traiter par "OnTick" sont reçus de l'extérieur dans une file d'attente avec des priorités. Dans d'autres gestionnaires, il est utile de s'assurer qu'aucun nouvel événement de ce type ne s'est produit, sinon les données du tick précédent sont invalides ou périmées.
Alors, qu'est-ce qui vous empêche de demander ce tick une fois dans le handler OnTick et de travailler ensuite avec les données résultantes ? C'est pratiquement inutile. Pourquoi s'embêter à le demander 100 fois (comme dans les tests ci-dessus), créant artificiellement un frein sur place.
C'est exactement ce que je fais dans le testeur
C'est à dire que le problème d'un code EA tordu est censé être résolu en compliquant le fonctionnement interne de MT. Ou avez-vous des mesures normales ?
Eh bien, le code est déterminé par des pratiques de codage communes, regardez le QB et l'utilisation des lignes de sécurité dans ces exemples
Je n'utilise pas SB, je mesure avec un profileur et je cherche des solutions depuis des mois, il y a eu un fil de discussion sur les tests de vitesse, avec des solutions alternatives.
la normalité du comptage ? c'est une pente glissante qu'il faudra traiter sérieusement, je suis content de mon EA pour l'optimisation, il y avait un passage à 18 mois 6 sec, maintenant 2.5 sec , imho j'ai fait un bon travail sur moi-même ))))
et non 0 comme actuellement, c'est-à-dire qu'effectivement REASON_PROGRAMME
Lors du redémarrage du terminal, il écrit continuellement et sans interruption dans le journal des enregistrements.
Le temps de la barre d'historique dans le journal est en constante augmentation. GBPUSD Le graphique quotidien est ouvert et s'agite - zéro, la première et la deuxième barre sont supprimées/créées. Et c'est ainsi que ça tourne en rond.
Je suis là à attendre. Est-ce qu'elle remplira toute la SSD avec ces bûches ou est-ce qu'elle s'arrêtera enfin...
Le journal d'hier est dans la remorque.
Erreur de compilation. Fonctionne bien dans les anciennes versions.