![MQL5 - Langage des stratégies de trading intégré au terminal client MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Il ne reste que la variante 0-INT_MAX dans les robots de combat. Je me suis arrêté en remarquant les freins.
Que faites-vous alors de cette histoire ?
Bien sûr, je peux changer le sous-compte chaque mois pour limiter l'historique des commandes à quelques centaines de milliers, mais ce n'est pas la solution :)
Que faites-vous alors de cette histoire ?
Je pourrais bien sûr modifier le sous-compte chaque mois pour limiter l'historique des commandes à cent mille, mais ce n'est pas la solution :)
Pour le moment, je constate que dans 99% des cas, seul HistorySelect(0, INT_MAX) doit être utilisé. Essayez de ne pas utiliser les autres options.
Probablement assez pour ne pas déplacer le début du cache, c'est-à-dire toujours interroger à partir de la même date (et le fait qu'elle soit égale à 0 n'a aucune importance).
Nous devons vérifier.
Probablement assez pour ne pas déplacer le début du cache, c'est-à-dire toujours interroger à partir de la même date (et le fait qu'elle soit égale à 0 n'a aucune importance).
Il doit être vérifié.
C'est possible. C'est difficile d'être un testeur pendant longtemps.
Résultat.
Sur chaque tique, il y a un problème.
SZY a installé Win10, LatencyMon montre que tout va bien.
Pourquoi fais-tu semblant d'être si naïf ?
Vous essayez de montrer que ce n'est pas bien de tuer le cache en premier lieu, c'est votre propre faute. C'est votre propre faute si vous tuez le cachet d'une grande histoire. Et c'est uniquement votre problème de modifier volontairement votre position. Vous pouvez trouver de nombreuses occasions de tuer/supprimer un tas de caches dans l'environnement MQL5.
Nous n'allons pas vous aider - dans n'importe quel langage de programmation, il existe un nombre considérable d'options pour se tirer une balle dans le pied et dans la tête.
Vous seriez traité normalement si vous indiquiez explicitement "regardez - c'est moi qui empoisonne la cachette exprès et me suicide".Probablement assez pour ne pas déplacer le début du cache, c'est-à-dire toujours interroger à partir de la même date (et le fait qu'elle soit égale à 0 n'a aucune importance).
Il doit être vérifié.
C'est exactement ce que j'ai explicitement décrit.
Si vous échantillonnez par date, n'essayez pas de faire un échantillon différent à chaque demande. Et avec à ce jour essayer de le mettre en avant.
Nous contrôlons spécifiquement la position et la réduisons automatiquement à INT_MAX si elle est supérieure ou égale à la date actuelle.
Vous essayez de montrer que tuer le cache n'est pas la norme, avant et maintenant. C'est votre propre faute pour avoir tué le cachet d'une grande histoire. Et c'est uniquement votre problème de faire des ajustements spécifiques à partir d'une position. Vous pouvez trouver de nombreuses occasions de tuer/supprimer un tas de caches dans l'environnement MQL5.
Une bibliothèque utilise HistorySelect de TimeCurrent. L'autre est de zéro. Pourquoi diable devrais-je entrer dans les entrailles des bibliothèques pour découvrir qu'elles ne sont pas compatibles entre elles en termes de performances ?
Un exemple succinct est de comprendre pourquoi des bibliothèques inoffensives peuvent interférer les unes avec les autres. Enfin, faites appel à votre esprit critique.
Une bibliothèque utilise HistorySelect de TimeCurrent. L'autre est de zéro. Pourquoi diable faut-il aller dans les entrailles des bibliothèques pour découvrir qu'elles ne sont pas compatibles entre elles en termes de performances ?
Un exemple succinct est de comprendre pourquoi des bibliothèques inoffensives peuvent interférer les unes avec les autres. Allumez enfin votre esprit critique.
C'est tellement tordu que c'est ton problème personnel que tu utilises des bibliothèques et que tu te casses la tête.
C'est ton propre problème d'utiliser les bibliothèques et de tourner la tête.
Pourquoi n'écrivez-vous pas vous-même tout depuis le début en Asm ? Il s'avère que tout va bien lorsque chacune des bibliothèques vole séparément. Mais dès que vous commencez à utiliser les deux à la fois, vous commencez à être lent.
Nous avons réussi à signaler des bogues à Microsoft, mais nous ne leur avons jamais écrit ou accusé qu'il existe environ N millions d'occasions de se tuer sur leur API.
Surtout en utilisant les bibliothèques d'autres personnes dans le processus.