ForumSections

Questions sur la POO dans MQL5 - page 35

Nouveau commentaire
Roman:

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.

BlackTomcat:

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 !

Igor Makanu:

Lesméthodes statiques ne diffèrent des fonctions que par leur portée.


Cette pratique est dangereuse

input int inInput = 0;

const bool Init = EventSetTimer(1);

void OnTimer()
{
  static int Input = inInput;
  
  Print(Input);
}


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

input long inMagic = 0;

void OnTick()
{
  static ORDER Orders[]; // Список ордеров по мэджику или что-то подобное, зависящая от входных.
}
fxsaber:

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 :

input int EAMagicNumber = 12345;
class CEA
{
public:
   static bool       NeedRecovery(int magic_)            {   return(true);    }
   bool              Recovery(int magic_,int inputparam) {   return(true);    }
                     CEA()                               {                    }
                     CEA(int inputparam)                 {                    }
                    ~CEA()                               {                    }
};

CEA *ea;

void OnStart()
{
   if(CheckPointer(ea)==POINTER_INVALID)
   {
      if(CEA::NeedRecovery(EAMagicNumber))   //если нашли открытые ордера с магиком
      {
         ea = new CEA();         // создали объект
         ea.Recovery(EAMagicNumber,11111);   // запустили восстановление ТС
      }else ea = new CEA(2222222);           //обычный запуск
   }
Igor Makanu

Il est plus logique de placer cette logique dans le constructeur.

fxsaber:

Lesméthodes statiques ne diffèrent des fonctions que par leur portée.

Faux. Ils ont également accès aux membres et méthodes non publics de la classe.
TheXpert:
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.

fxsaber:

Il y a ici un malentendu terminologique.

Après tout, la visibilité et l'accès sont des concepts différents et il est préférable de ne pas les confondre.
fxsaber:

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 :

input int EAMagicNumber = 12345;
class CEA
{
public:
   static bool       NeedRecovery(int magic_)            {   return(true);    }  //тут проверки
                     CEA(int magic_)                     {                    }  //это обычный запуск если все ОК
                     CEA(int magic_, int recoveryparam)  {                    }  //тут аварийное восстановление
                    ~CEA()                               {                    } };

CEA *ea;

//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
void OnStart()
{  if(CheckPointer(ea)==POINTER_INVALID)
   {  if(CEA::NeedRecovery(EAMagicNumber))   //если нашли откртые ордера с магиком
      {  
         ea = new CEA(EAMagicNumber,11111);  // запустили востановление ТС
      }
      else ea = new CEA(EAMagicNumber);      //обычный запуск
   } 
}
LeXpert:
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
c'est pourquoi j'ai une question, où pourrais-je mettre un moyen de détecter que la dernière exécution s'est écrasée, maintenant ma structure de code est compacte, tout suit clairement le modèle que j'ai montré ci-dessus.
1...282930313233343536373839404142...96
Nouveau commentaire