Bisogno di aiuto da sviluppatori e programmatori MT4 - pagina 7

Nuovo commento
 

Che mucchio di sciocchezze...

Penso anche che il looping dell'EA sia un mauvais ton. Cambiare i parametri solo dopo la fine del ciclo di avvio è perfettamente logico. Il topicstarter non ha potuto fare a meno di capire che il problema è nel suo ciclo infinito, visto che non è un dilettante. Tuttavia, non ha scritto nulla nel primo post sul loop infinito nell'Expert Advisor. Personalmente non ho implementato tali sistemi nei miei EA, ma a quanto ho capito, a giudicare dai miei post,non è mai successo prima- la finestra dei parametri negli EA in loop semplicemente non veniva aperta. Questo significa che l'affermazione di TC"Porta all'incompatibilità fondamentale degli EAs esistenti con le nuove builds di MT4." non è vera - nelle vecchie builds di MT4, tali EAs non permettevano anche di cambiare i parametri, perché era impossibile aprire la finestra fino alla fine del ciclo.

EventSetMillisecondTimer risolve il problema. Ma quanto tempo fa è apparsa questa funzione? Non c'era solo EventSetTimer prima? Con un intervallo minimo di chiamata di 1 secondo un tale evento è completamente inutile quando si scrivono sistemi per il trading reale, quando ci possono essere decine di tick per ogni simbolo al secondo.

Non c'è ancora alcun riferimento a questa funzione nell'aiuto sui timer! L'ho appena scoperto per caso, come suggerimento quando si entra nell'EventSet.

 
C'è però, a mio parere, per quanto riguarda l'inizializzazione delle variabili, un problema e un'incongruenza nel nuovo MQL 4/5: quando la deinizializzazione e l'inizializzazione non cancellano e ricreano gli oggetti dinamici nelle variabili globali. Cioè, se i parametri dell'EA vengono letti nei costruttori di oggetti creati dinamicamente in variabili globali e l'EA continua a lavorare con essi, quando i parametri vengono cambiati, l'EA continuerà a lavorare come se i parametri non fossero cambiati. Secondo me, non è logico e le variabili globali dovrebbero essere deinizializzate dopo la deinizializzazione dell'EA e poi reinizializzate prima dell'inizializzazione dell'EA. Questo è attualmente risolto mettendo l'inizializzazione e la cancellazione di tali variabili in OnInit e OnDeinit
 
AntFX:
C'è però, a mio parere, un problema e un'incongruenza nel nuovo MQL 4/5: quando si deinizializza e si inizializza non c'è cancellazione e ricreazione di oggetti dinamici nelle variabili globali...
Questo è un buon punto... ma apparentemente lo sviluppatore ha deciso che solo la "nascita" e la "morte" del programma possono influenzare il valore iniziale delle variabili globali... quindi nel blocco di deinizializzazione dobbiamo azzerare i valori delle variabili globali o assegnarli ai valori iniziali ....
 
AntFX:
C'è però, a mio parere, un problema e un'incongruenza nel nuovo MQL 4/5: la deinizializzazione e l'inizializzazione non rimuovono e ricreano gli oggetti dinamici nelle variabili globali. Cioè, se i parametri dell'EA vengono letti nei costruttori di oggetti creati dinamicamente in variabili globali e l'EA continua a lavorare con essi, quando i parametri vengono cambiati, l'EA continuerà a lavorare come se i parametri non fossero cambiati. Secondo me, non è logico e le variabili globali dovrebbero essere deinizializzate dopo la deinizializzazione dell'EA e poi reinizializzate prima dell'inizializzazione dell'EA. Questo è attualmente risolto mettendo l'inizializzazione e la cancellazione di tali variabili in OnInit e OnDeinit

Sì, è un vero rastrellamento, soprattutto considerando che la documentazione (néqui néqui) non sottolinea che il caricamento ora non è legato 1 a 1 con l'evento di inizializzazione. Ecco alcune parole come questa:

Le variabili globali sono inizializzate una volta subito dopo che il programma è stato caricato nella memoria del terminale client.

non è chiaramente sufficiente per indicare allo sviluppatore che le successive modifiche dei parametri saranno deinizializzate e inizializzate, MA NON il corrispondente scarico e caricamento.

 
marketeer:

Sì, è un vero rastrellamento, soprattutto considerando che la documentazione (néqui néqui) non sottolinea che il caricamento ora non è legato 1 a 1 con l'evento di inizializzazione. Ecco alcune parole come questa:

Le variabili globali sono inizializzate una volta subito dopo che il programma è stato caricato nella memoria del terminale client.

non è ovviamente sufficiente per attirare l'attenzione dello sviluppatore sul fatto che le successive modifiche dei parametri deinizializzano e inizializzano, MA NON eseguono lo scarico e il caricamento corrispondenti.

Non c'è bisogno di caricare/scaricare e reinizializzare le variabili. Il programmatore deve occuparsi dell'inizializzazione delle variabili.

 
Contender:

Non c'è bisogno di caricare/scaricare e reinizializzare le variabili. Il programmatore deve occuparsi dell'inizializzazione delle variabili.

È quello che voglio dire: non è chiaro quando viene eseguita questa inizializzazione. Codice con una variabile globale:

int x = 0;

anche questa è un'inizializzazione. Ma non è scritto chiaramente nella documentazione che questa non è solo inizializzazione dal punto di vista di MC.

 
In senso stretto, ci sono ora 2 diverse inizializzazioni in MT: una eseguita quando il programma viene caricato, e una quando l'"ambiente" viene cambiato quando viene chiamato OnInit. È già abbastanza grave che questo debba essere portato alla luce.
 
marketeer:
In senso stretto, ci sono ora 2 diverse inizializzazioni in MT: una viene eseguita all'avvio del programma e l'altra viene eseguita quando si cambia l'"ambiente" al momento della chiamata OnInit. La cosa brutta è che questo deve essere portato alla luce.

Una partenza a freddo viene fatta quando il programma viene avviato. La memoria viene assegnata alle variabili e inizializzata con valori iniziali.

Quando è in funzione - avviamento a caldo. Qui il programmatore deve occuparsi dell'inizializzazione delle variabili e questo è un bene.

 
Contender:

Una partenza a freddo viene fatta quando il programma viene avviato. La memoria viene assegnata alle variabili e inizializzata con valori iniziali.

Quando è in funzione - avviamento a caldo. In questo caso il programmatore deve occuparsi dell'inizializzazione delle variabili e questo è un bene.

Buono o cattivo, è una questione filosofica... Ma il fatto che ci siano 0.0 informazioni su di esso nella documentazione non è buono...
 
denkir:
Se sia buono o cattivo è una questione filosofica... Ma il fatto che ci siano 0.0 informazioni su di esso nella documentazione non è buono...

E, se ricordo bene, non c'era una cosa del genere prima, cioè è, per dirla in modo gentile, una "caratteristica" aggiunta appositamente per "comodità" dei programmatori, ma che viola l'invarianza dei codici esistenti (scritti per le regole di inizializzazione precedenti). Così, il principio immutabile di preservare la compatibilità del vecchio codice con le nuove versioni del software, quando possibile, non è osservato.

Nessuno è contrario a nuove funzionalità e ottimizzazioni. Ma perché non farlo in modo tale che il vecchio codice non sia rotto? In particolare, per questa nuova inizializzazione potremmo assegnare un comando aggiuntivo del preprocessore simile a #property strict. Per esempio, potrebbe essere #proprietà lazyinit, e se è specificato dallo sviluppatore (cioè esplicitamente, il che significa che è consapevole della nuova inizializzazione in mql), allora ci rallegriamo dell'ottimizzazione ottimizzata. E se non è specificato, allora siamo contenti che il codice precedente funzioni coerentemente, senza alcuno scavo e ricerca di posti dove potrebbero rimanere le variabili globali, che ora non solo devono essere dichiarate, ma anche inizializzate separatamente in OnInit. Per ogni variabile di questo tipo, ci saranno 2 linee di codice invece di una.

12345678
Nuovo commento