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
Si l'objet a accompli sa tâche, pourquoi le garder en mémoire ?
N'y aura-t-il pas une fuite de mémoire ?
Il le fera, surtout s'il n'est pas supprimé même dans OnDeinit.
Vous n'êtes pas obligé de le garder en mémoire, si vous n'en avez vraiment plus besoin. Mais le plus souvent, il arrive qu'un objet soit créé et utilisé à une itération... Et puis à la deuxième itération... Et ainsi de suite. Et puis, sous certaines conditions, un autre objet de la même classe est créé, et vous travaillez déjà avec deux ou plusieurs objets de cette classe, dont chacun est nécessaire tout au long de la vie de l'EA.
Cela se produira, surtout s'il n'est pas supprimé même dans OnDeinit.
Vous n'êtes pas obligé de le garder en mémoire, si vous n'en avez vraiment plus besoin. Mais le plus souvent, il arrive qu'un objet soit créé et utilisé à une itération... Et puis à la deuxième itération... Et ainsi de suite. Et puis, sous certaines conditions, un autre objet de la même classe est créé, et vous travaillez déjà avec deux ou plusieurs objets de cette classe, dont chacun est nécessaire tout au long de la vie de l'EA.
Vous voulez donc dire qu'une fuite de mémoire contrôlée est meilleure que la recréation d'objets ?
C'est-à-dire un gain de temps, en échange de démons contrôlés ?
C'est dangereux de ne pas les perdre plus tard.
écrit en utilisant le modèlehttps://www.mql5.com/ru/forum/85652/page24#comment_13054686 de l'expert
Un modèle assez flexible, permettant d'ajouter différents "plus" en "2 clics" et le code s'avère lisible et logique, mais... Je suis revenu à un paradigme discuté selon lequel une bonne classe ne devrait pas avoir de méthodes statiques.
Cela semble bien en théorie, mais en pratique... Pas à mon avis, du moins pour les problèmes de MQL.
Selon le modèle, la classe EA a été écrite et une méthode publique est lancée dans OnTick(). Mais pendant l'initialisation de l'EA, je veux vérifier s'il y a des ordres ouverts et les prendre :
1. écrire une fonction dans le OnTick() ci-dessous qui, si elle trouve un ordre ouvert via l'assistant, crée un objet EA ; si aucun ordre n'est trouvé, l'objet EA est initialisé selon la logique de base - l'objet EA est créé uniquement en temps de trading et implémente la logique du TS dans le futur
2. écrire une classe statique en EA, qui implémente les éléments 1
Essentiellement les points 1 et 2 sont les mêmes, la différence est que dans l'étape 1, j'ajoute une fonction qui n'aurait de sens que pendant l'initialisation de l'EA (la première exécution), mais imho, cela surcharge le code - une fonction sera appelée une fois pour toute l'exécution du programme !
si vous créez une méthode statique ( pp.2 ), alors elle sera logique et lisible - la méthode n'est nécessaire que pour l'initialisation et définit le moment où l'objet EA doit être créé - vous ne devez passer à cette méthode que le nombre magique.
A mon sens, interdire d'utiliser les méthodes statiques quand c'est pratique... pour ne pas dire plus !
Lesméthodes statiques ne diffèrent des fonctions que par leur portée.
Cette pratique est dangereuse
Si vous changez l'entrée pendant que l'EA est en cours, l'entrée ne changera pas.
En conséquence, elle est chargée de
Si vous changez l'entrée pendant que l'EA est en cours, l'entrée ne changera pas.
Je suis conscient de cela, et dans mon TS vous ne pouvez pas changer les paramètres d'entrée pendant que l'EA fonctionne, le temps d'exécution est séparé de la logique du TS.
Ma question est purement théorique, je ne veux pas surcharger le code, donc je cherche la possibilité de restaurer le TS après un crash quelque part, jusqu'à présent je vois ça comme ça :
Il est plus logique de placer cette logique dans le constructeur.
Lesméthodes statiques ne diffèrent des fonctions que par leur portée.
incorrect. également l'accès aux membres et méthodes non publics de la classe.
Il y a ici un malentendu terminologique. La "zone de visibilité" ne concerne pas seulement la personne qui voit la méthode. Mais aussi ce qu'il voit lui-même.
Il y a ici un malentendu terminologique.
Il est plus logique de placer cette logique dans le constructeur.
Oui, c'est une meilleure solution ! Il y a donc une méthode en moins.
C'est comme ça que ça devrait être :
après tout, la visibilité et l'accès sont des concepts différents et il est préférable de ne pas les mélanger