
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Se il numero di oggetti è noto in anticipo ed è costante durante l'esecuzione del programma, allora il nuovo non è necessario. In tutti gli altri casi, avete bisogno di nuovo.
No, ecco il mio esempiohttps://www.mql5.com/ru/forum/160683/page861#comment_11840254
è conveniente passare parametri al costruttore e se l'utente cambia le impostazioni, è più veloce uccidere la classe in OnDeinit() e poi crearla con i nuovi parametri in OnInit()
;)
no, ecco il mio esempiohttps://www.mql5.com/ru/forum/160683/page861#comment_11840254
è conveniente passare parametri al costruttore e se l'utente cambia le impostazioni, è più veloce uccidere la classe in OnDeinit() e poi crearla con i nuovi parametri in OnInit()
;)
I parametri possono anche essere passati al costruttore senza new.
I parametri possono essere passati al costruttore senza new.
Quindi, come cambierete i campi di classe (le impostazioni EA modificate dall'utente)? - Scriverai un altro metodo? Credevo che nell'ultima pagina vi stavate battendo per"una variabile in piùper un puntatore". "e qui c'è tutto un metodo!
;)
e? e come cambierete i campi di classe (le impostazioni EA modificate dall'utente)? - Scriverai un altro metodo? Pensavo che nell'ultima pagina vi stavate battendo per"una variabile in piùper il puntatore"."con cui stavi lottando, ed ecco un intero metodo!
;)
no way ;)
cambiare le impostazioni EA
no way ;)
cambiare le impostazioni EA
Bella imboscata.
Tuttavia, preferirei aggiungere un metodo per cambiare i parametri, ma non usare new solo per i parametri.Bella imboscata.
Tuttavia, preferisco aggiungere un metodo per cambiare i parametri, ma non usare new solo per i parametri.non usare il nuovo è una superstizione? )))
imho, se è conveniente, bisogna usarlo! - Il tuo esempio sarà riscritto in 2 clic usando new e tutto funzionerà correttamente e gestirà la situazione quando l'utente cambia le impostazioni
non usare il nuovo è superstizione? )))
imho, se è conveniente, bisogna usarlo! - Il tuo esempio si riscrive in 2 clic usando new e tutto funziona correttamente e gestisce la situazione quando l'utente cambia le impostazioni
Non superstizione, solo pigrizia, storicamente, dovuta alle circostanze. Dovete scrivere cancellazione e farlo in Deinit(). Ma la funzione Deinit() non era presente nel template di default. Ora guardo - il modello EA ha Deinit(), ma prima non c'era.
Non superstizione, solo pigrizia, storicamente, dovuta alle circostanze. Dovremmo scrivere cancellare e farlo in Deinit(). Ma la funzione Deinit() non era presente nel template di default. Sto cercando ora - c'è Deinit() nel modello EA, ma prima non c'era.
Non scrivere cancellare - tutto funzionerà correttamente, questo peccato (voglio dire superstizione) ) ) prenderà il controllo del terminale e borbotterà nel log "48 byte di memoria persa", "2 oggetti di tipo CX rimasti" e "oggetti non cancellati rimasti".
HH: nel template dell'indicatore non c'è Deinit() - questo è fastidioso
non scrivere cancellare - tutto funzionerà correttamente, questo peccato (voglio dire superstizione)) ) prenderà il controllo del terminale e borbotterà nel suo log "48 byte di memoria persa", poi "2 oggetti di tipo CX rimasti" e "oggetti non cancellati rimasti"
SZY: in un modello di creazione dell'indicatore non c'è Deinit() - si sforza
Funzionerà senza cancellare, ma è inutile. Ma il terminale si occupa di questo problema? Segnala solo le perdite di memoria, ma non dedica gli stessi oggetti.