Questions sur la POO dans MQL5 - page 7

Nouveau commentaire
 
Dmitry Fedoseev:

Si le nombre d'objets est connu à l'avance et qu'il est constant pendant l'exécution du programme, alors new n'est pas nécessaire. Dans tous les autres cas, il faut du neuf.

Non, voici mon exemplehttps://www.mql5.com/ru/forum/160683/page861#comment_11840254

il est pratique de passer des paramètres au constructeur et si l'utilisateur change les paramètres, il est plus rapide de tuer la classe dans OnDeinit() et ensuite de la créer avec les nouveaux paramètres dans OnInit()

;)

 
Igor Makanu:

non, voici mon exemplehttps://www.mql5.com/ru/forum/160683/page861#comment_11840254

il est pratique de passer des paramètres au constructeur et si l'utilisateur change les paramètres, il est plus rapide de tuer la classe dans OnDeinit() et de la créer ensuite avec les nouveaux paramètres dans OnInit()

;)

Les paramètres peuvent également être passés au constructeur sans new.

 
Dmitry Fedoseev:

Les paramètres peuvent être passés au constructeur sans new.

Alors, comment allez-vous modifier les champs de classe (paramètres EA modifiés par l'utilisateur) ? - Voulez-vous écrire une autre méthode ? Je pensais qu'à la dernière page, vous vous battiez pour"une variable de pluspour un pointeur"."et là, vous avez toute une méthode !

;)

 
Igor Makanu:

et ? et comment allez-vous modifier les champs de classe (paramètres EA modifiés par l'utilisateur) ? - Allez-vous écrire une autre méthode ? Je croyais qu'à la dernière page, vous vous battiez pour"une variable de pluspour le pointeur"." qui vous posait problème, et voici toute une méthode !

;)

input int a1=1;
input int a2=2;

class CX{
   public:
   void CX(int a,int b){
   
   }
};

CX cx(a1,a2);
 
Dmitry Fedoseev:

pas du tout ;)

#property copyright "Copyright 2018, MetaQuotes Software Corp."
#property link      "https://www.mql5.com"
#property version   "1.00"
#property strict
input int a1=1;
input int a2=2;
//+------------------------------------------------------------------+
class CX
  {
public:
   int a1,a2;
   void CX(int a,int b) {a1=a;a2=b; }
  };
CX cx(a1,a2);  
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
int OnInit()
  {

   return(INIT_SUCCEEDED);
  }
//+------------------------------------------------------------------+
void OnDeinit(const int reason)
  {
  }
//+------------------------------------------------------------------+
void OnTick()
  {
      Comment("cx.a1 = ",cx.a1,"\ncx.a2 = ",cx.a2);
  }
//+------------------------------------------------------------------+

modifier les paramètres de l'EA

 
Igor Makanu:

pas du tout ;)

modifier les paramètres de l'EA

Belle embuscade.

Cependant, je préférerais ajouter une méthode pour modifier les paramètres, mais ne pas utiliser new juste à cause des paramètres.
 
Dmitry Fedoseev:

Belle embuscade.

Néanmoins, je préfère ajouter une méthode pour changer les paramètres, mais ne pas utiliser new juste à cause des paramètres.

ne pas utiliser le neuf est une superstition ? )))

imho, si c'est pratique, vous devez l'utiliser ! - Votre exemple sera réécrit en 2 clics en utilisant new et tout fonctionnera correctement et gèrera la situation lorsque l'utilisateur change les paramètres.

#property strict
input int a1=1;
input int a2=2;
//+------------------------------------------------------------------+
class CX
  {
public:
   int a1,a2;
   void CX(int a,int b) {a1=a;a2=b; }
  };
CX *cx;
//+------------------------------------------------------------------+
int OnInit()
  {
   cx = new CX(a1,a2);
   return(INIT_SUCCEEDED);
  }
//+------------------------------------------------------------------+
void OnDeinit(const int reason)
  {
  delete cx;
  }
//+------------------------------------------------------------------+
void OnTick()
  {
      Comment("cx.a1 = ",cx.a1,"\ncx.a2 = ",cx.a2);
  }
//+------------------------------------------------------------------+
 
Igor Makanu:

ne pas utiliser de nouvelles est une superstition ? )))

imho, si c'est pratique, vous devez l'utiliser ! - Votre exemple sera réécrit en 2 clics en utilisant new et tout fonctionnera correctement et gèrera la situation lorsque l'utilisateur change les paramètres.

Pas de superstition, juste de la paresse, historiquement, en raison des circonstances. Vous devez écrire delete et le faire dans Deinit(). Mais la fonction Deinit() n'était pas présente dans le modèle par défaut. Maintenant, je regarde - le modèle EA a Deinit(), mais il n'était pas là avant.

 
Dmitry Fedoseev:

Pas de superstition, juste de la paresse, historiquement, en raison des circonstances. Nous devrions écrire delete, et le faire dans Deinit(). Mais la fonction Deinit() n'était pas présente dans le modèle par défaut. Je regarde maintenant - il y a Deinit() dans le modèle EA, mais il n'était pas là avant.

N'écrivez pas supprimer - tout fonctionnera correctement, ce péché (je veux dire superstition) ) ) prendra le contrôle du terminal et marmonnera dans le journal "48 octets de mémoire perdue", "2 objets de type CX restants" et "objets non supprimés restants".

HH : dans le modèle d'indicateur, il n'y a pas de Deinit() - c'est ennuyeux.

 
Igor Makanu:

ne pas écrire supprimer - tout fonctionnera correctement, ce péché (je veux dire superstition)) ) prendra le contrôle du terminal et marmonnera dans son journal "48 octets de mémoire perdue", puis "2 objets de type CX restants" et "objets non supprimés restants".

SZY : dans un modèle de création de l'indicateur il n'y a pas de Deinit() - il se redresse

Ça marchera sans supprimer, mais c'est inutile. Mais le terminal prend-il en charge ce problème ? Il ne signale que les fuites de mémoire, mais il ne consacre pas les mêmes objets.

1234567891011121314...96
Nouveau commentaire