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

Nuovo commento
 
Ilya Malev:

Ho ottenuto "stack overflow" )

Immagino che sia uno scarafaggio dopo tutto...

Beh, questo non è il compilatore, ma a runtime, e il compilatore dovrebbe reagire.

Ecco cosa ho provato in VS 2010:

class A
 {
  public:
   virtual int f2() = 0;
 };

class B : public A
{
 public:
  virtual int f2() { return A::f2(); }
};

B b;

Ottengo un errore di compilazione: Errore 1 errore LNK2001: simbolo esterno non risolto "public: virtual __thiscall A::f2(void)".

Ma Metaeditor non dice una parola. Non va bene.

 
Si scopre che chiamare una funzione antenata con = 0 diventa chiamare se stessa. Se si cattura questo errore da soli, si potrebbe essere in grado di trarne beneficio...
 
Alexey Navoykov:

Questo è il modo in cui il compilatore dovrebbe reagire.

Ho provato questo in VS 2010:

Ottengo un errore di compilazione: Errore 1 errore LNK2001: simbolo esterno non risolto "public: virtual __thiscall A::f2(void)".

Metaeditor non dice una parola. Non va bene.

Alexey, per favore spiegami, perché se mql è una copia di C, deve essere assolutamente identico e un passo a sinistra, un passo a destra - plotone d'esecuzione?

Solo perché gli sviluppatori sono stati negligenti? Ma qualsiasi linguaggio è costruito su cicli e condizioni. Tutto il resto è nel trailer. Perché nessuno pretende che qualsiasi altro linguaggio sia simile al C nella parte OOP o in qualsiasi altro modo?

 
Alexey Viktorov:

Alexey, puoi spiegarmi sulle tue dita perché se mql è come C, allora deve essere assolutamente identico e un passo a sinistra, un passo a destra - plotone d'esecuzione?

Solo perché gli sviluppatori sono stati negligenti? Ma qualsiasi linguaggio è costruito su cicli e condizioni. Tutto il resto è nel trailer. Perché nessuno pretende che qualsiasi altro linguaggio sia simile al C nella parte OOP o in qualsiasi altro modo?

Non si tratta di essere completamente identici. Si tratta di funzionalità che implementate devono funzionare correttamente e coerentemente. Ma prima si grida: mostratemi un altro linguaggio che funziona diversamente. E poi quando il C++, che funziona in modo diverso (correttamente), viene dato come esempio, si inizia un vecchio sproloquio su come MQL non è C++ e non dovrebbe essere identico.
 
Alexey Viktorov:

Puoi mostrarci un esempio in cui tutto questo può facilitare la scrittura del codice, accorciarlo o almeno proteggerlo dagli errori? E per favore, non funzioni astratte, ma funzioni vicine alle reali condizioni di trading in un Expert Advisor o indicatore.

Assolutamente no. I ragazzi stanno solo cercando di trasformare le loro fantasie in realtà.

 
Dmitry Fedoseev:

Assolutamente no. I ragazzi stanno solo cercando di trasformare le loro fantasie in realtà.

Mi sembra che sia un esercizio molto utile - allungare la fantasia nella realtà. Questo è lo scopo dello sviluppo!
Discussione molto illuminante. (Grazie.
 
Alexey Navoykov:

Sì, ma ho usato un'opzione alternativa per molto tempo: tutte le interfacce sono originariamente progettate come una classe template intermedia:

In questo modo si può creare una catena di eredità composta da un numero qualsiasi di tali interfacce. Sì, ovviamente non puoi fare dynamic_cast con loro, ma non è così spesso necessario. Il compito principale è quello di passarli nelle funzioni.

L'ho letto attentamente, è una mossa interessante, comunque. Non ci avevo pensato prima =) Sperimenterò anch'io, a mio piacimento...

 
Nikolai Semko:
Per me, quindi esercizio molto utile - per allungare la fantasia sulla realtà. Questo è il punto dello sviluppo!
Una discussione molto illuminante. Grazie.

Gli sviluppatori ci hanno ascoltato e hanno deciso di correggere questo bug su cui tutti hanno inciampato per anni.

Ma l'atteggiamento distruttivo di alcuni utenti del forum è certamente sorprendente - non si sviluppano e cercano di ostacolare gli altri con notevole persistenza.

 

>> Sì, ovviamente non si può fare dynamic_cast con loro, ma non è una necessità così frequente.

Perché non lo fai tu, nessun problema ) Ma poi appare il tuo incubo principale - il non rilevamento degli errori di casting in fase di compilazione :)

 
Ilya Malev:

>> Sì, ovviamente non si può fare dynamic_cast con loro, ma non è una necessità così frequente.

Perché non lo fai tu, nessun problema ) Ma poi appare il tuo incubo principale - il non rilevamento degli errori di casting in fase di compilazione :)

Dopo tutto, la catena di eredità potrebbe essere in qualsiasi modo: Interface<CBase> o Interface<C<B<A<CBase>>>>, ci sono innumerevoli varianti. Dovremo lanciare CBase in modo coerente a tutte le possibili varianti, il che non è realistico.

Ricordo di aver pianificato di implementare la memorizzazione delle informazioni sulle interfacce nell'oggetto classe stesso, e in aggiunta ai pad di interfaccia esistenti, fare classi di interfaccia indipendenti che avrebbero funzionato come un wrapper sopra il nostro pad. Ma poi sono arrivato alla conclusione che tutto questo era inutile e superfluo. In pratica, non ho mai visto la necessità di lanciare una classe base a qualsiasi interfaccia, semplicemente non ha alcun senso. L'unica opzione è scoprire se la classe supporta questa interfaccia per scopi di debug, ma non abbiamo bisogno del casting per questo.

12345678910111213141516...28
Nuovo commento