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

Nuovo commento
 
pavlick_:

Circa il multi-passaggio - affrettato, ingenuamente pensava che il mcl lo avrebbe permesso

Quindi ci sono delle variabili qui. E con le funzioni - sì, è multi-passabile, quindi tutto era giusto. Il problema sorge proprio a causa dell'ordine di inizializzazione delle funzioni. In breve, in C++ c'è un ordine rigido relativo a variabili, funzioni e tipi. E in MQL è tutto diverso.
 
Alexey Navoykov:
Ну вот я с этого и начинал разговор тут. Планировал тоже заменять все статики на глобалы (хоть это и жесть конечно).  Но как показано выше, с шаблонами такое не прокатит.  С макросами тоже.  А я всё это широко применяю.  Поэтому и сделал свою реализацию.  Хотя она конечно не решает всех проблем.  Динамические массивы по-прежнему нельзя инициализировать, константные типы тоже.  Поэтому их однозначно придётся выносить на глобальный уровень

Uso anche ampiamente i modelli e le macro, ma considero le funzioni libere solo come elementi architettonici ausiliari (e generalmente indesiderabili). Quando tutte le implementazioni sono impacchettate all'interno di oggetti e le statiche sono dichiarate solo a livello di classe, appaiono bug fastidiosi, a parte il fatto che a volte è difficile capire la logica della loro corretta sequenza di dichiarazioni, in modo che il compilatore non imprechi...

 
Alexey Navoykov:
Quindi ci sono delle variabili qui. E con le funzioni, sì, è multi-passabile, quindi tutto era giusto. Il problema sorge proprio a causa dell'ordine di inizializzazione delle funzioni. In breve, in C++ c'è un ordine rigido che si applica a variabili, funzioni e tipi. E in MQL tutto è diverso.

I passaggi multipli sono cattivi in ogni caso - si può incontrare ricorsione, deadlock ecc. Ma il lato positivo è che si può fare. Quindi solo saggiamente, con cautela (cioè dichiarazione in avanti), e non come ora con il compilatore multi-pass - come se per ogni dichiarazione in avanti di funzione è fatta, prima o poi questo rastrello colpirà la tua fronte.

 
pavlick_:

Il multipassaggio è un male in ogni caso - si può incorrere in ricorsione, deadlock, ecc. Ma è possibile fare la dichiarazione in avanti sul lato positivo. Quindi solo saggiamente, con attenzione, e non come ora con il compilatore multipass - come se per qualsiasi dichiarazione di funzione in avanti è fatto, prima o poi questo rastrello colpirà la fronte.

Sono d'accordo. Questo argomento è stato discusso un po' prima. È quello che a molti qui piace del linguaggio - che non ci si preoccupa dell'ordine di dichiarazione delle funzioni. Inutile dire che io stesso ne ero felice qualche tempo fa). Ma la sua tediosità mi irritava sul lato positivo. Ma con l'esperienza arriva la comprensione.

 
Ilya Malev:

Uso anche ampiamente i modelli e le macro, ma considero le funzioni libere solo come elementi architettonici ausiliari (e generalmente indesiderabili). Quando tutte le implementazioni sono impacchettate all'interno di oggetti e le statiche sono dichiarate solo a livello di classe, appaiono bug fastidiosi, a parte il fatto che a volte è difficile capire la logica della loro corretta sequenza di dichiarazioni, in modo che il compilatore non imprechi...

Sono d'accordo, se tutto è chiaramente allineato in OOP allora non solo le funzioni libere non sono necessarie, ma anche i metodi generici, ma qui abbiamo a che fare con un ibrido sottosviluppato tra C++ e C#, ecco perché dobbiamo implementare molte cose con delle stampelle )
 
Alexey Navoykov:
Sono d'accordo, se tutto è chiaramente allineato in OOP, allora non solo le funzioni libere non sono necessarie, ma anche i metodi template.

I metodi template sono necessari ovunque non si voglia scrivere un mucchio di codice ripetitivo, sia OOP che non OOP. Le funzioni libere sono un'altra cosa - si tratta di stili di programmazione diversi.

 
Ilya Malev:

I metodi template sono necessari ovunque non si voglia scrivere un mucchio di codice ripetitivo, che sia OOP o non OOP

In OOP, le interfacce sono progettate per fare questo.
 
Alexey Navoykov:
In OOP, le interfacce sono state inventate per questo scopo.

Le interfacce sono un po' diverse. Se voglio che lo stesso codice faccia lo stesso lavoro con tipi diversi a seconda della classe del parametro (senza dichiarare classi aggiuntive), le interfacce non aiutano.

 
Ilya Malev:

Le interfacce sono un po' diverse. Se voglio che lo stesso codice faccia lo stesso lavoro con tipi diversi a seconda della classe del parametro (senza dichiarare classi aggiuntive), l'interfaccia non aiuta.

Se i parametri sono di tipi diversi, allora ha senso fare diversi metodi sovraccaricati con tipi corrispondenti. Dovrai comunque separarli in qualche modo nella funzione. Quindi è meglio dividerli in funzioni separate, piuttosto che creare un casino che prende anche un tipo impersonale, cioè per errore puoi passarci qualsiasi cosa e ottenere un errore di compilazione all'interno della libreria, che non è buono. E forse anche no, che è doppiamente cattivo).

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

 
Alexey Navoykov:


In breve, le funzioni template sono una stampella in OOP a tutti gli effetti.

Quindi eccoci qui.

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

Caratteristiche del linguaggio mql5, consigli e trucchi

Alexey Navoykov, 2019.01.25 10:11

Beh, è così che ho iniziato la conversazione qui. Stavo pensando di sostituire anche tutte le statiche con le globali (anche se è una cosa crudele, ovviamente). Ma come mostrato sopra, non funzionerà anche con i modelli e le macro. E io li uso tutti ampiamente. Ecco perché ho fatto la mia implementazione, anche se non risolve tutti i problemi: gli array dinamici non possono ancora essere inizializzati, e nemmeno i tipi costanti. Ecco perché dovranno sicuramente essere globalizzati.
Quindi si scopre che tutto il tuo codice è fatto con le stampelle? Non è niente di personale.
123456789101112...28
Nuovo commento