Domande su OOP in MQL5 - pagina 8
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
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"
HH: nel template dell'indicatore non c'è Deinit() - questo è fastidioso
Perché non creare un oggetto invece di un puntatore? Allora non borbotterà nemmeno - il sottosistema terminale lo rintraccerà e lo inchioderà quando necessario.
Funzionerà senza cancellare, ma non serve a niente. Ma il terminale si occupa di questo problema? Segnala solo le perdite di memoria, ma non dedica gli stessi oggetti.
Il terminale si occuperà di cancellare gli oggetti creati da new nel caso in cui i puntatori ad essi siano impilati in un oggetto noto al terminale, ad esempio ArrayObj, List, ecc.
Perché non creare un oggetto invece di un puntatore? Allora non borbotterà nemmeno - il sottosistema terminale lo rintraccerà e lo inchioderà quando necessario.
perchéhttps://www.mql5.com/ru/forum/85652/page7#comment_12329866
Il terminale si occuperà di cancellare gli oggetti creati da new nel caso in cui i puntatori ad essi siano impilati in un oggetto noto al terminale, ad esempio ArrayObj, List, ecc.
non sempre conveniente la distruzione non supervisionata, ma devo controllare, forse mi sbaglio - uso raramente CObject
perchéhttps://www.mql5.com/ru/forum/85652/page7#comment_12329866
Beh, questo è un caso molto particolare e grottescamente semplificato, secondo me. Creare un oggetto che non può essere cambiato, in modo che per cambiare i suoi campi, bisogna inchiodarlo e crearne uno nuovo...
E se abbiamo bisogno di cambiare un paio di campi oggetto e lasciare altri campi con le informazioni necessarie? IMHO - meglio occuparsi dell'interattività e della gestibilità di ogni oggetto (grazie all'ereditarietà), che sedersi con una pistola e sparare ai conigli ad ogni starnuto.
Anche se, ad essere onesti - a volte è più veloce uccidere e crearne uno nuovo, che cercare l'oggetto desiderato tra un gran numero e cambiarlo. A meno che, naturalmente, non ci sia un collegamento diretto ad esso...
Beh, questo è un caso molto particolare e grottescamente semplicistico, secondo me. Creare un oggetto assolutamente immutabile, in modo che per cambiare i valori dei suoi campi bisogna inchiodarlo e farne nascere uno nuovo...
E se abbiamo bisogno di cambiare un paio di campi oggetto e lasciare altri campi con le informazioni necessarie? IMHO - meglio occuparsi dell'interattività e della gestibilità di ogni oggetto (grazie all'ereditarietà), che sedersi con una pistola e sparare ai conigli ad ogni starnuto.
Anche se, ad essere onesti - a volte è più veloce uccidere e crearne uno nuovo, che cercare quello richiesto tra un gran numero e cambiarlo. A meno che, ovviamente, tu non abbia un link diretto ad esso...
hmmm, sei fuori strada .... Sì, ma non così ))))
come è conveniente, è così che si dovrebbe usare! - e questi esempi dal "primo libro di testo di c++" possono essere tirati nella vostra esperienza per tutta la vita.... Come esempio, ho smontato una parte decente del codice di @fxsaber e mi sono fatto usare #define il più possibile - il codice è diventato non solo più breve, ma davvero più leggibile e ha eliminato gli errori di battitura - insegnano così tanto nei libri C++? ;)
Anche se, ad essere onesti - a volte è più veloce uccidere e crearne uno nuovo, che cercarne uno richiesto tra un gran numero e cambiarlo. Certo, se non c'è un indirizzo diretto...
e sulle basi del libro... Secondo le "buone regole di allevamento" nella programmazione, ci si aspetta quanto segue: si deve dichiarare una variabile e inizializzarla immediatamente (questo permette di evitare bug durante il debug), in OOP il costruttore serve a questi scopi - si è creato un oggetto e si inizializza tutto
se avete bisogno di "tirare l'intero codice dopo un semplice oggetto", avrete bisogno di un metodo per reinizializzare tutti i campi della classe - perché duplicare questo? - uccidere/creare = risultato.... ma di nuovo, è una questione di gusto e di religione.
perchéhttps://www.mql5.com/ru/forum/85652/page7#comment_12329866
Non sono sempre a mio agio con la distruzione non supervisionata, ma dovrò controllare, forse mi sbaglio - uso raramente CObject
Ma tu usi le liste. E lì è lo stesso. Bene, a meno che il flag di gestione della memoria FreeMode() non sia azzerato per la lista - in questo caso il terminale non traccia - tutto è intrapreso dall'utente. Ma questa situazione è necessaria per essere in grado di cambiare, cancellare, ordinare e fare qualcos'altro con una copia della lista - infatti la lista è creata con puntatori a oggetti, e se si crea una nuova lista una copia di una delle liste, e si inizia a cambiare gli oggetti nella nuova lista (ci sono puntatori a oggetti), allora anche nella lista originale gli oggetti saranno cambiati (perché lavoriamo con puntatori). Questo è per mantenere l'originale e giocherellare con la sua copia, poi è necessario abbandonare la bandiera di gestione della memoria per una copia: FreeMode(false) - allora la copia diventa una copia indipendente, e si può tranquillamente lavorare con gli oggetti in essa, senza influenzare l'originale. E ricordate, che quando slegate la copia della lista dal sottosistema terminale, allora per la cancellazione degli oggetti della lista ora siamo noi stessi responsabili. Potete tracciarlo e cancellarlo in OnDeinit(), questo nel caso più semplice e se la lista-copia ci è nota prima, o creare una lista-oggetto, che mette sempre liste appena create, non conosciute prima con la bandiera della gestione manuale della memoria. Allora il terminale rintraccerà questo oggetto lista e cancellerà correttamente le liste impilate in esso.
Il terminale si fa carico della cancellazione degli oggetti creati da new nel caso in cui i puntatori ad essi siano impilati in un oggetto noto al terminale, ad esempio ArrayObj, List, ecc.
Allora non ci sarà nemmeno un messaggio di perdita.
Allora non ci sarà nemmeno la segnalazione di una fuga di notizie.
Sì, non lo farà. Perché non ci sarà una perdita.
Se abbiamo creato un nuovo oggetto da qualche parte e abbiamo ricevuto un puntatore ad esso, dobbiamo cancellare questo oggetto dal puntatore dato. Significa che abbiamo bisogno di tracciare il puntatore. Per questo scopo, le liste o gli array di puntatori a oggetti, offerti in SB, sono molto buoni. Ma potete anche occuparvi del tracciamento e del controllo degli oggetti appena creati. Ma, per quanto mi riguarda, perché scrivere tonnellate di codice se è già fornito?
allora dovrebbero cancellare questo oggetto da questo puntatore.
Ma, per quanto mi riguarda, perché scrivere tonnellate di codice se è già fornito?
Di quali tonnellate stiamo parlando? Tutto quello che ti è sfuggito è segnalato dal terminale e il posto per cancellarlo è anche noto - OnDeint() .... Questa discussione si è ridotta a una discussione su un cavallo sferico nel vuoto? )))
hmm, mi stai prendendo in giro..... così, ma non così ))))
come è conveniente, è così che si dovrebbe usare! - e questi esempi dal "primo libro di testo s++" possono essere tirati nella vostra esperienza per tutta la vita.... Come esempio, ho smontato una parte decente del codice di @fxsaber e mi sono fatto usare #define il più possibile - il codice è diventato non solo più breve, ma davvero più leggibile e senza errori di battitura - insegnano così tanto nei libri C++? ;)
E riguardo alle basi del libro... Le buone regole di allevamento dicono: proclamare una variabile e inizializzarla immediatamente (questo permette di evitare bug durante il debug), in OOP il costruttore serve a questo scopo - hai creato un oggetto e inizializzi tutto
se avete bisogno di "tirare l'intero codice dopo un semplice oggetto", avrete bisogno di un metodo per reinizializzare tutti i campi della classe - perché duplicare questo? - uccidere/creare = risultato.... ma di nuovo, è una questione di gusto e di religione.
Non sto parlando di una completa reinizializzazione di un oggetto, ma parziale - quando un paio di campi devono essere cambiati e un paio di dozzine di altri contengono ancora le informazioni di cui avete bisogno... Possiamo o non possiamo voler cambiare i campi, ma abbiamo bisogno di metodi per cambiarli. A meno che - di nuovo - non stiamo parlando di un semplice oggetto con un solo campo. Se ce ne sono due o più - potresti già aver bisogno di cambiarne uno, lasciando gli altri invariati.
Ma forse stiamo parlando di cose diverse?