Fragen zu OOP in MQL5 - Seite 7

Neuer Kommentar
 
Dmitry Fedoseev:

Wenn die Anzahl der Objekte vorher bekannt ist und während des Programmablaufs konstant bleibt, wird new nicht benötigt. In allen anderen Fällen brauchen Sie neue.

Nein, hier ist mein Beispielhttps://www.mql5.com/ru/forum/160683/page861#comment_11840254

es ist praktisch, Parameter an den Konstruktor zu übergeben, und wenn der Benutzer die Einstellungen ändert, ist es schneller, die Klasse in OnDeinit() zu beenden und sie dann mit den neuen Parametern in OnInit() zu erstellen

;)

 
Igor Makanu:

nein, hier ist mein Beispielhttps://www.mql5.com/ru/forum/160683/page861#comment_11840254

es ist praktisch, Parameter an den Konstruktor zu übergeben, und wenn der Benutzer die Einstellungen ändert, ist es schneller, die Klasse in OnDeinit() zu beenden und sie dann mit den neuen Parametern in OnInit() zu erstellen

;)

Parameter können auch ohne new an den Konstruktor übergeben werden.

 
Dmitry Fedoseev:

Parameter können ohne new an den Konstruktor übergeben werden.

Wie werden Sie also Klassenfelder ändern (vom Benutzer geänderte EA-Einstellungen)? - Werden Sie eine weitere Methode schreiben? Ich dachte auf der letzten Seite, Sie würden für"eine weitereVariable für einen Zeiger" kämpfen."Und hier haben Sie eine ganze Methode!

;)

 
Igor Makanu:

und? und wie werden Sie Klassenfelder ändern (vom Benutzer geänderte EA-Einstellungen)? - Werden Sie eine weitere Methode schreiben? Ich dachte auf der letzten Seite, Sie würden für"eine weitereVariable für den Zeiger" kämpfen.", mit dem Sie zu kämpfen hatten, und hier ist eine ganze Methode!

;)

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

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

CX cx(a1,a2);
 
Dmitry Fedoseev:

auf keinen Fall ;)

#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);
  }
//+------------------------------------------------------------------+

die EA-Einstellungen ändern

 
Igor Makanu:

auf keinen Fall ;)

EA-Einstellungen ändern

Cooler Überfall.

Ich würde es jedoch vorziehen, eine Methode zum Ändern der Parameter hinzuzufügen, aber nicht new nur wegen der Parameter zu verwenden.
 
Dmitry Fedoseev:

Cooler Überfall.

Nichtsdestotrotz ziehe ich es vor, eine Methode zum Ändern von Parametern hinzuzufügen, aber verwende new nicht nur wegen der Parameter.

ist es ein Aberglaube, nichts Neues zu benutzen? )))

Imho, wenn es praktisch ist, muss man es benutzen! - Ihr Beispiel wird in 2 Klicks mit new umgeschrieben und alles wird korrekt funktionieren und die Situation behandeln, wenn der Benutzer die Einstellungen ändert

#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:

ist es Aberglaube, nichts Neues zu benutzen? )))

Imho, wenn es praktisch ist, muss man es benutzen! - Ihr Beispiel wird in 2 Klicks neu schreiben mit neuen und alles wird richtig funktionieren und behandeln Situation, wenn der Benutzer Einstellungen ändert

Das ist kein Aberglaube, sondern einfach Faulheit, historisch bedingt, durch die Umstände. Sie müssen delete schreiben und es in Deinit() tun. Die Funktion Deinit() war jedoch nicht standardmäßig in der Vorlage enthalten. Jetzt schaue ich nach - die EA-Vorlage hat Deinit(), aber sie war vorher nicht da.

 
Dmitry Fedoseev:

Das ist kein Aberglaube, sondern einfach Faulheit, historisch bedingt, durch die Umstände. Wir sollten delete schreiben und es in Deinit() tun. Die Funktion Deinit() war jedoch standardmäßig nicht in der Vorlage enthalten. Ich schaue jetzt nach - es gibt Deinit() in der EA-Vorlage, aber es war vorher nicht da.

Schreiben Sie nicht löschen - alles wird richtig funktionieren, diese Sünde (ich meine Aberglaube) ) ) übernimmt das Terminal und murmelt in das Protokoll "48 Byte ausgelaufener Speicher", "2 Objekte vom Typ CX übrig" und "ungelöschte Objekte übrig".

HH: in der Indikatorvorlage gibt es kein Deinit() - das ist ärgerlich

 
Igor Makanu:

schreiben Sie nicht löschen - alles wird richtig funktionieren, diese Sünde (ich meine Aberglaube)) ) übernimmt das Terminal und murmelt in sein Protokoll "48 Bytes an ausgelaufenem Speicher", dann "2 Objekte des Typs CX übrig" und "ungelöschte Objekte übrig".

SZY: in der Vorlage für die Erstellung des Indikators gibt es kein Deinit() - es belastet

Ohne Löschen funktioniert es zwar, aber es ist nutzlos. Aber kümmert sich das Terminal um dieses Problem? Es meldet nur Speicherlecks, widmet sich aber nicht denselben Objekten.

1234567891011121314...96
Neuer Kommentar