OOP, modelli e macro in mql5, sottigliezze e usi - pagina 6

Nuovo commento
 
Alexey Viktorov:

Ecco qui.

Quindi tutti i vostri codici sono fatti con le stampelle? Non è niente di personale.
Sì, all'incirca così, perché MQL non ha una vera e propria OOP. Inoltre ci sono un sacco di bug, che segnalo regolarmente, ma senza successo. E mi devo difendere dai bug con le stampelle, che ci posso fare.
 

Ecco come facciamo.

Se la variabile statica è inizializzata con una costante, questa inizializzazione sarà fatta al passo di inizializzazione globale, come prima
Altrimenti (chiamata o inizializzazione di variabile), la variabile statica sarà inizializzata sul primo riferimento (sarà come in C++), questo riferimento stesso sarà avvolto in una condizione con variabile globale/flag implicita, per esempio

per il codice MQL:

class CFoo { };

void func(bool f)
  {
   if(f)
     {
      static CFoo foo;
      foo.MakeMeHappy();
     }
  }

Verrà generato il seguente pseudocodice

CFoo static_func_foo={}; // zeromem only
bool static_func_foo_init=false;

void func(bool f)
  {
   if(f)
     {
      if(!static_func_foo_init)
        {
         static_func_foo.CFoo();  // constructor call
         static_func_foo_init=true;
        }

      static_func_foo.MakeMeHappy();
     }
  }
 
Alexey Navoykov:

Dovete comunque separarli in qualche modo nella funzione.

Non necessariamente e non sempre. Non vi darò esempi, per non sporcare il thread.

 
Ilyas:

Ecco come faremo.

Grandi notizie! Gli dei hanno ascoltato le nostre preghiere, dopotutto).
 
Alexey Navoykov:
Sì, all'incirca così, perché MQL non ha una vera e propria OOP. Inoltre ci sono un sacco di bug, che segnalo regolarmente, ma senza successo. E contro i bug mi devo difendere con le stampelle, che ci posso fare.

Mi hai confuso. Se in ... leggere le tue parole

Forum sul trading, sistemi di trading automatico e test di strategia

Peculiarità di mql5, consigli e trucchi

Alexey Navoykov, 2019.01.25 11:44

Se i parametri sono di tipi diversi, è ragionevole fare diversi metodi sovraccaricati con i tipi corrispondenti. Dovete comunque condividerli nelle funzioni, quindi è meglio dividerli in funzioni separate, piuttosto che fare un pasticcio, che in più prende un tipo impersonale, cioè potete erroneamente passargli tutto e ottenere un errore di compilazione all'interno della libreria, che non è buono. O potrebbe anche non ottenere, il che è doppiamente male).

In breve, in OOP a tutti gli effetti le funzioni template sono una stampella (con poche eccezioni).

E non c'è una vera e propria OOP in MQL... Mancano anche le stampelle? Non capisco assolutamente nulla.
 
MQL è tutto buono con l'OOP, e se viene aggiunta l'ereditarietà multipla (almeno per le interfacce, perché sono inutili nella loro forma attuale), sarà perfetto.
 
Ilya Malev:
MQL è OK con OOP, se aggiungono l'ereditarietà multipla(almeno per le interfacce, perché sono inutili nella loro forma attuale), sarà perfetto.

Quindi, le interfacce sono la base della normale OOP, e voi state dicendo che tutto va bene in MQL.

 
Alexey Navoykov:

Quindi le interfacce sono la base della normale OOP, eppure dite che tutto va bene in MQL.

La base dell'OOP normale è il polimorfismo, non le interfacce. Le interfacce sono la base di una certa struttura di classe. In generale, mi piacerebbe parlare di questi argomenti, ma temo che questo thread non sia il luogo adatto.

 
Ilya Malev:

La base dell'OOP normale è il polimorfismo, non le interfacce. Le interfacce sono la base di una certa struttura di classe. In generale, sarei felice di discutere questi argomenti, ma temo che questo ramo non sia adatto.

Stiamo discutendo delle particolarità del linguaggio MQL e l'assenza di eredità multipla è una caratteristica abbastanza comune).

Ok, la base è certamente il polimorfismo, ma senza interfacce separate non è conveniente nell'uso. Questo porta spesso a passare oggetti come argomenti di template invece di interfacce.

Ho descritto qui la mia variante di simulazione di interfacce multiple. Di conseguenza, una classe può essere dichiarata come

class A : public Interface1<Interface2<Interface3<CBase>>>
{
 ...
};
 
Alexey Navoykov:

Stiamo discutendo delle peculiarità del linguaggio MQL e l'assenza di eredità multipla è proprio una peculiarità).

Ok, la base ovviamente è il polimorfismo, ma senza interfacce separate non è conveniente nell'uso. Questo porta spesso a passare oggetti come argomenti di template invece di interfacce.

Ho descritto la mia variante di imitazione delle interfacce multiple qui. Di conseguenza, una classe può essere dichiarata come tale:

Secondo me, non è tutto negativo. Non ci sono così tante interfacce principali di base in C# che i loro metodi non possano essere ridotti a una superclasse di base e poi ereditati.

P.S. Implementare qualcosa di multiplo attraverso costruzioni come <<<<>>>> è un po' una rottura di palle. È meglio fare le funzioni attraverso gli operatori, per esempio a==b chiama a.compareto( b ), a[comparer]==b chiama comparer.compare(a,b) ecc.
12345678910111213...28
Nuovo commento
Motivazione: