Domande su OOP in MQL5 - pagina 9

Nuovo commento
 
Igor Makanu:

Di quali tonnellate stiamo parlando? tutto ciò che è stato trascurato sarà riportato dal terminale, il posto dove eliminarlo è anche noto - OnDeint() .... Questa discussione è diventata una discussione su un cavallo sferico nel vuoto? )))

No. Lasciate che il cavallo vada dove deve andare.

Ma stiamo parlando della creazione di oggetti precedentemente sconosciuti. E non conosciamo solo le loro proprietà, ma anche il numero di oggetti creati.

Naturalmente, per un oggetto possiamo creare un puntatore e lavorare con quell'oggetto tramite questo puntatore. Ma se non sappiamo in anticipo di quanti puntatori avremo bisogno, che tipo di vuoto è questo? È solo uno dei più semplici e immediatamente disponibili: memorizzare i puntatori nelle liste. Possono essere presi dalla lista. Bene, ogni oggetto può avere il suo identificatore (il metodo Type()), con il quale si può identificare l'oggetto puntatore. È possibile identificare con precisione un oggetto (oltre al suo tipo l'oggetto può essere dotato di altre proprietà, che lo distinguono dagli oggetti dello stesso tipo).

In generale - mi sembra di parlare di strutture più complesse, che richiedono la classificazione degli oggetti, liste per la loro memorizzazione e metodi di lavoro con oggetti che possono non solo memorizzare e dare informazioni su richiesta, ma anche "vivere e crescere" interagendo con il programma, di volta in volta essi stessi cambiando e segnalando le loro azioni.

Forse sono andato troppo lontano e ho appena discusso un oggetto in cui due campi devono essere cambiati durante l'inizializzazione e non devono cambiare in alcun modo durante la vita dell'oggetto. Che senso ha avere un oggetto se ci sono variabili di ingresso?

 
Nessuno è obbligato a rimuovere un oggetto tranne colui che lo ha creato. Anche se in alcuni casi succede, non c'è da fidarsi. Se l'hai creato tu, cancellalo.
 
Dmitry Fedoseev:
Nessuno è obbligato a cancellare un oggetto, tranne colui che lo ha creato. Anche se questo accade in alcuni casi, non c'è da fidarsi. Se l'hai creato tu, cancellalo.

Questo è vero. Ma non è di questo che stiamo parlando. Non è vero?

Stiamo parlando di metodi con i quali gli oggetti non sono sicuramente persi, e si possono trovare senza ambiguità.

Quando create un oggetto, siate consapevoli di esso e non perdetelo, in modo che possa essere correttamente cancellato in seguito e non ci siano perdite di memoria a causa della perdita del puntatore dell'oggetto (abbiamo iniziato con la perdita di memoria nell'esempio in cui il puntatore all'oggetto passato nella funzione è stato riassegnato all'oggetto appena creato nel corpo della funzione).

E ognuno ha le sue preferenze - ad alcuni piace una cosa, ad altri un'altra. Ma dobbiamo conoscere ognuno dei nostri oggetti - anche se sono due o duemila e due - in modo da poterli cancellare in seguito. E se li cancelleremo noi stessi con delete o lasceremo che list li cancelli con Clear() o in loop con list e delete o in qualche altro modo - non si tratta di questo.

 
Artyom Trishkin:

In generale, mi sembra di parlare di strutture più complesse, che richiedono la classificazione degli oggetti, liste per la loro memorizzazione e metodi di lavoro con gli oggetti, che non solo possono memorizzare e dare informazioni su richiesta, ma anche "vivere ed evolvere" interagendo con il programma, di volta in volta cambiando se stessi e riferendo delle loro azioni.

Forse sono andato troppo lontano e dobbiamo solo discutere un oggetto in cui due campi devono essere cambiati all'inizializzazione e non devono cambiare in alcun modo durante la vita? Che senso ha avere un oggetto se ci sono variabili di input?

Questo è uno strano concetto di OOP. Prima di tutto, OOP è conveniente - si scrive una volta e poi si creano nuove istanze dell'oggetto.

Tornando all'inizio della discussione, ecco il mio esempio, lo uso spessohttps://www.mql5.com/ru/forum/160683/page861#comment_11840254

Devo limitare il mio trading a un intervallo di tempo ora e 2 la prossima volta... 4...

il mio esempio di 2 click è modificato per questo compito:

int OnInit()
{
   Work1=new CWorkTime(StartHour1,StartMinute1,StopHour1,StopMinute1);
   Work2=new CWorkTime(StartHour2,StartMinute2,StopHour2,StopMinute2);
   Work3=new CWorkTime(StartHour3,StartMinute3,StopHour3,StopMinute3);
   Work4=new CWorkTime(StartHour4,StartMinute4,StopHour4,StopMinute4);
}


Non so, ma pensando in categorie che l'OOP è solo per avvolgere tutto in una classe e lì è un miracolo - la mia superclasse e può fare entrambe le cose... E se la classe è di 10 stringhe, non hai bisogno di OOP - perché limitarti e ingannare tutti?

Io uso OOP dove mi conviene, la discussione è chiaramente passata alla religione - proibire o usare OOP ))))

 
Igor Makanu:

Questa è una strana idea di OOP, OOP è prima di tutto conveniente - scrivere una volta, poi creare nuove istanze dell'oggetto

Tornando all'inizio della discussione, ecco il mio esempio, lo uso spessohttps://www.mql5.com/ru/forum/160683/page861#comment_11840254

Devo limitare il mio trading a un intervallo di tempo ora e 2 la prossima volta... 4...

il mio esempio di 2 click è modificato per questo compito:


Non so, ma pensando in categorie che l'OOP è solo per avvolgere tutto in una classe e lì è un miracolo - la mia superclasse e può fare entrambe le cose... E se la classe è di 10 stringhe, non hai bisogno di OOP - perché limitarti e ingannare tutti?

dove mi conviene, è lì che uso OOP, chiaramente la discussione è passata alla religione - proibire o usare OOP ))))

Decisamente - non sono io quello che si addentra in questa religione, dato che io stesso uso attivamente OOP.

Per esempio: e se avessimo bisogno di altri intervalli? Dovremmo crearne di nuovi? Per quale motivo? Se si può gestire con una lista senza interferire con il codice del programma.

Sembra che stiamo parlando di cose diverse. Sto parlando di usabilità, e tu... Anch'io parlo di usabilità, ma tu stai mostrando del codice che non è usabile. Forse solo esagerato, naturalmente, e non l'ho capito...

 
Artyom Trishkin:

Per esempio: e se sono necessari più intervalli? Si devono creare nuovi WorkNNN? Qual è il punto? Se riesci a gestire una lista senza interferire con il codice del programma...

Se abbiamo bisogno di usare liste o array di istanze di classe, non è un grosso problema, ma è più facile usare un array per questo esempio, e faremo solo un ciclo:

bool DisableTrade=false;
   for(int i=0;i<ArraySize(Work);i++)
     {
      if(Work[i].Disable()) {DisableTrade=true; break}
     }
   if(DisableTrade)
     {
      Comment("Не торговое время!!! Сопровождение открытых ордеров");
     }
   else...

Artyom Trishkin:

Sembra che stiamo parlando di cose diverse. Sto parlando di usabilità, e tu... Anche io parlo di usabilità, ma il codice che mostri non è conveniente. Forse è solo esagerato, naturalmente, e non l'ho capito...

Purtroppo è impossibile scrivere codice universale. Anche se si scrive codice universale, la sua ulteriore modifica sarà un processo noioso e di conseguenza il codice universale sarà più dispendioso in termini di risorse - in generale si può parlare di questo all'infinito, una volta ho scritto, come disse uno dei famosi programmatori -"il codice deve eseguire il suo compito! - basta così". Tutto il resto è ... beh, è un desiderio di fare casino o... diciamo per creare! )))

 
Artyom Trishkin:

///

Per esempio: e se sono necessari più intervalli? Si devono creare nuovi WorkNNN? Qual è il punto? Se si può gestire con una lista senza interferire con il codice del programma.

///

Allora non ci saranno parametri numerici di intervallo nella finestra delle proprietà. Non sarete in grado di ottimizzarli. Non è un'opzione.

Anche la creazione di un nuovo oggetto per ogni intervallo non è l'opzione migliore. Tuttavia, porterà a prestazioni più lente. Se dovessimo creare una classe, dovremmo crearne una che aggiunga i parametri degli intervalli in un array. Sarà più veloce.

 
Dmitry Fedoseev: rmosa. Se dovete fare una classe, dovrebbe essere tale da aggiungere i parametri degli intervalli in un array. Sarà più veloce.

non fa assolutamente differenza se si fa una classe o una funzione in cui si aggiungono() diversi parametri, se si creano diverse classi con parametri individuali

SZZ: non dimenticate che se scrivete una grande funzione sotto forma di un lungo "nastro di cavallo" - la cache della CPU non sarà sempre utilizzata efficacemente, anche se ci può essere un guadagno in un tale "nastro di cavallo" quando si prevedono le transizioni.... Solo i test possono dimostrarlo, ma su un PC specifico e un compilatore specifico...

 
Dmitry Fedoseev:

Allora non ci saranno parametri di intervallo numerico nella finestra delle proprietà. Non sarete in grado di ottimizzarlo. Non è un'opzione.

Creare un nuovo oggetto per ogni intervallo non è nemmeno l'opzione migliore. Dopo tutto, questo porterà a prestazioni più lente. Se dovessimo creare una classe, dovremmo crearne una che aggiunga i parametri degli intervalli in un array. Sarebbe più veloce.

D'accordo. Di nuovo, tutto si riduce ai metodi per impostare i campi di checkout. E come trasferirli dai parametri di input all'oggetto che memorizza tutti gli intervalli è una questione di tecnica. Anche se è possibile ricreare tutti gli oggetti nella lista degli intervalli e quando si cambia solo uno di essi - è una questione di praticità e di "preoccuparsi/non preoccuparsi" di cambiare i dati quando si scrive il codice.

 
Roman:

Puoi spiegare il senso della creazione di un oggetto dinamico usando l'operatore new?

Quando un oggetto viene creato automaticamente, l'oggetto classe viene creato nello stack ed è più veloce di un oggetto dinamico in termini di tempo di esecuzione.
Quando si crea un oggetto dinamicamente, un oggetto di classe viene creato in memoria (nell'heap) coinvolgendo il gestore di memoria del sistema operativo, il processo è più lento.

Ecco le domande:
Se la creazione automatica è più veloce, allora perché è meglio usare oggetti dinamici?
Controllare esplicitamente l'allocazione della memoria?
Eliminare un possibile stack overflow?
E non perdere un oggetto inaspettatamente?
Perché se lo stack trabocca, l'oggetto sarà automaticamente cancellato?

Buon pomeriggio. La memoria del computer ha le stesse prestazioni indipendentemente dal fatto che sia usata in un contesto stack o heap. La gestione dinamica della memoria stessa dipende dall'implementazione del raccoglitore di rifiuti: per esempio, può essere il conteggio dei riferimenti come in Python (variante più lenta) o l'analisi delle epoche di generazione degli oggetti con l'attraversamento del grafico di esecuzione nel processo in background (Net CLR). Quale variante sia usata in MQL è sconosciuta, ma possiamo supporre che sia estremamente efficiente, perché l'utente di MQL5 ha accesso all'operatore di cancellazione direttamente, il che semplifica notevolmente il lavoro del GC stesso. Pertanto, le vostre preoccupazioni circa l'overhead quando si usa new sono infondate - sentitevi liberi di usare la memoria dinamica.

Per quanto riguarda lo "stack overflow", l'unico modo in cui si può incontrare questo caso nei sistemi moderni è quando si usa una ricorsione complessa o si fa un errore nell'algoritmo ricorsivo. Un programma moderno lavora sempre in modalità protetta OC nello spazio di indirizzi virtuale, con caricamento dinamico delle pagine di memoria, quindi non preoccupatevi: lo stack non traboccherà:)

12345678910111213141516...96
Nuovo commento