Domande su OOP in MQL5 - pagina 90

Nuovo commento
 
Igor Makanu:

se nel mio esempio:

copiare i valori asc e bid nel metodo onTick() e usare _Ask, _Bid (commercio virtuale) nel resto dei metodi

sarà come lavorare con le variabili globali?

ZS: come opzione, posso naturalmente passare per riferimento &tick a tutti i metodi, ma ancora una volta mi chiedo quale sia più efficiente

Se questo argomento è ancora pertinente, vorrei far notare che l'opzione di mantenere i campi è sia meno efficiente che meno corretta concettualmente. In linea di principio, i due concetti sono quasi sempre correlati.
Il codice pulito (senza effetti collaterali) è sempre meglio ottimizzato dal compilatore e più facile da capire.
Se il vostro oggetto è destinato a cambiare il suo stato sotto l'influenza di dati di input, non dovrebbe memorizzare quei dati di input (tranne che per scopi di caching).
Bisogna separare le mosche dalle cotolette.

 

Una volta ho fatto una domanda su due modi per inizializzare le variabili in una classe. Questo:

class CA{
   protected:
      int val;
   public:
      CA(){
         val=0;
      }      
};

E questo:

class CA{
   protected:
      int val;
   public:
      CA():val(0){
      }      
};

Ho chiesto qual è il vantaggio del secondo modo e mi è stato detto che si possono inizializzare i membri statici con esso. Ma i membri statici non sono inizializzati in questo modo.

Quindi la domanda è la stessa - qual è la differenza di principio e qual è il vantaggio del secondo modo?

 

Cita

Хочется закончить свою песнь важными словами. Любые описанные механизмы, принципы и паттерны, как и ООП в целом не стоит применять там, где это бессмысленно или может навредить. Это ведет к появлению статей со странными заголовками типа «Наследование — причина преждевременного старения» или «Синглтон может приводить к онкологическим заболеваниям».
 
Dmitry Fedoseev:

Una volta ho fatto una domanda su due modi per inizializzare le variabili in una classe. Eccone uno come questo:

https://www.mql5.com/ru/forum/85652/page45#comment_15975127

Dmitry Fedoseev:

Ho chiesto qual è il vantaggio del secondo modo e mi è stato detto che i membri statici possono essere inizializzati da esso. Ma i membri statici non sono inizializzati in questo modo.

Sono campi costanti , non statici.

class CA
{
protected:
   const int         val;
   static int        static_val;
public:
                     CA(): val(0) { }
};
static int CA::static_val = 12345;
Dmitry Fedoseev:

Quindi la domanda è sempre la stessa - qual è la differenza di principio e qual è il vantaggio del secondo modo?

Se scartiamo l'affermazione "è considerata cattiva forma", allora qualunque cosa sia più conveniente, è quello che useremo, imho.

 
Sì, esatto, costante, confuso)
 

Ricomincio il topic, ho cancellato il post precedente, pensavo di averlo capito da solo....


ecco il codice:

class CSetting  
{
public:
   enum T            {T1, T2, T3, T4, T5, T6, T7, T8};
   enum D            {D1, D2, D3, D4, D5, D6, D7, D8};
   enum V            {V1, V2, V3, v4};
private:
   int               param1, param2;
   T                 t;
   D                 d;
   V                 v;
public:
                     CSetting(const int in_param1,const int in_param2,const T in_t,const D in_d,const V in_v);
  };
//+------------------------------------------------------------------+
CSetting::CSetting(const int in_param1,const int in_param2,const T in_t,const D in_d,const V in_v)
   : param1(in_param1),
     param2(in_param2),
     t(in_t),
     d(in_d),
     v(in_v)
  {}

//--- input parameters
input int              Input_p1 = 1;   // p1 = -1000 ... +1000
input int              Input_p2 = 2;   // p2 = -1000 ... +1000
input CSetting::T      Input_T = CSetting::T::T1;
input CSetting::D      Input_D = CSetting::D::D1;
input CSetting::V      Input_V = CSetting::V::V1;

Voglio riempire 3 enum e 2 int dalla sezione privat di CSetting con un int in cui bit per bit memorizzerò questi dati, ho abbozzato il codice:

class CSetting
  {
public:
   enum T            {T1, T2, T3, T4, T5, T6, T7, T8};
   enum D            {D1, D2, D3, D4, D5, D6, D7, D8};
   enum V            {V1, V2, V3, v4};
private:
   int               param1, param2;
   T                 t;
   D                 d;
   V                 v;
public:
                     CSetting(const uint data);
  };
//+------------------------------------------------------------------+
CSetting::CSetting(const uint data)
{
   v = (V)(data & 0x3);
   d = (D)((data >> 2) & 0x7);
   t = (T)((data >> 5) & 0x7);
   uint tmp = ((data >> 8) & 0xFFF);
   param2 = (tmp & 0x800) == 0x800 ? -(int)(tmp & 0x7FF) : (int)(tmp & 0x7FF);
   tmp = data >> 20;
   param1 = (tmp & 0x800) == 0x800 ? -(int)(tmp & 0x7FF) : (int)(tmp & 0x7FF);
}
//+------------------------------------------------------------------+
//--- input parameters
input int DATA         = 0xFFFFFFFF;

in teoria, dovrebbe funzionare, prendo i 2 + 3 +3 bit inferiori dai dati per enum, e i restanti 24 bit dall'int per riempire param1 e param2, mantenendo il 12° bit come carattere del numero


Come faccio a controllare se c'è un errore? )))

o sarebbe grato per le idee di qualcun altro su come salvare questi dati su int

 
In alternativa: t+d*10+v*100
 
Igor Makanu:

come si controlla se ci sono errori? )))

Il solito modo - imballare, disimballare, controllare se è identico. preferibilmente controllare tutti i casi limite.
 
Dmitry Fedoseev:
o t+d*10+v*100

questo non funzionerà,

dovete spostare bit per bit o moltiplicare/splittare per 2, che è equivalente a spostare

TheXpert:
bene, come al solito - imballalo, disimballalo, controlla l'identità. preferibilmente controlla tutti i casi limite.

Quindi, sì... logicamente

ma non avevo intenzione di fare il packing - sto diminuendo il numero di variabili di input per l'ottimizzatore e ho bisogno di molti passaggi di GA su di loro, in modo che GA non converga rapidamente


I casi limite sono già stati controllati, ma dall'esperienza.... gli insetti sono così astuti!!! )))

HH: posso naturalmente reimpostare il ciclo da 0...MAX_UINT in un file e guardarlo visivamente, ma non è la migliore opzione, imho.

 
Igor Makanu:

non funzionerà,

...

Perché non dovrebbe funzionare? Tre enumerazioni, nessuna delle quali superiore a 10. Aritmetica delle scuole elementari di secondo grado.

1...8384858687888990919293949596
Nuovo commento