Argomento interessante per molti: cosa c'è di nuovo in MetaTrader 4 e MQL4 - grandi cambiamenti in arrivo - pagina 10
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 dimenticate che abbiamo un ottimo inliner in funzione, che scarica un sacco di piccole funzioni, quindi non c'è perdita di velocità.
E nella maggior parte dei casi, le chiamate alle funzioni virtuali tramite vtable sono ottimizzate in chiamate dirette. Questo è uno dei metodi efficaci dell'ottimizzatore. Il che, insieme all'inlining multiplo, permette di sbarazzarsi quasi completamente delle chiamate complesse a più livelli e di far sembrare il codice piatto.
Non dimenticate che abbiamo un ottimo inliner in funzione, che scarica un sacco di piccole funzioni, quindi non c'è perdita di velocità.
E nella maggior parte dei casi, le chiamate alle funzioni virtuali tramite vtable sono ottimizzate in chiamate dirette. Questo è uno dei metodi efficaci dell'ottimizzatore. Questo, insieme all'inlining multiplo, permette di sbarazzarsi quasi completamente delle chiamate complesse a più livelli e di far sembrare il codice piatto.
:) divertente. E nessuno sostiene che il compilatore ottimizza perfettamente il codice, sto solo mostrando al mio amico perché non mi abbasso prima di SB.
Ok, usiamo degli esempi:
è sostituito in pratica da una semplice funzione standard
CopyBuffer(...);Abbiamo l'arte per l'arte. E così su ogni elemento che fa qualcosa (il resto, come capite, è scritto perché gli elementi finali funzionino).
Sì, sono d'accordo sulla versatilità, sì, sono d'accordo sul codice ben strutturato (si può dire, è un campione da analizzare).
Ma qual è il succo del discorso? Il punto è che questa libreria è principalmente necessaria per il Wizard MQL5 e come tutorial su OOP.
Sto semplicemente facendo capire al compagno perché non cado davanti al SB.
Sì, sì, lo sottolineo di nuovo - non ho nessuna seria obiezione a nessuno dei vostri argomenti. Una discussione su questo sarebbe più religiosa che oggettiva.
Beh, proprio sul tuo esempio, personalmente ME, e NEL MIO CASO, sembra più accettabile proprio la prima variante del codice, a causa di tutte quelle inclusioni multilivello che garantiscono la compatibilità dell'indicatore con tutte le interfacce, a partire da CObject e fino a CiCustom.
Ma, d'altra parte - tutte le serie temporali e gli indicatori sono creati su richiesta, impilati in una singola collezione, e quindi disponibili per tutti gli utenti. E quando abbiamo bisogno di copiare un buffer solo una volta, ci chiediamo perché prendersi tutto questo disturbo.
Quindi, in un caso semplice, ovviamente, sarebbe molto più facile usare CopyBuffer().
Ma cosa succede se abbiamo una dozzina di utenti di un dato buffer? Nel mio caso - tutti lo chiederanno, il buffer sarà creato e tutti gli altri avranno un riferimento ad esso. E se usiamo CopyBuffer() "direttamente" - avrò dieci copie invece di una. E quando si usa CopyBuffer() in modo più astuto, si ottengono cose con il tracciamento di chi e quale buffer è stato allocato, che è abbastanza equivalente in termini di costi all'incapsulamento che hai menzionato.
Personalmente sono per la ragionevolezza - non ha senso fare una trama così grande con OOP per un solo posto. Se abbiamo molti utenti, allora l'approccio OOP, secondo me, si giustifica.
Poi è il momento di introdurre le eccezioni in modo che un codice possa essere compilato sia per mql4 che per mql5.
La questione dell'unificazione incombe.
Stavo pensando che quando si fondono due linguaggi, le direttive di compilazione condizionale come #ifdef sono assolutamente necessarie - questo semplificherebbe l'unificazione dei codici tra le due piattaforme, e le API dipendenti dalla piattaforma sarebbero definite al momento della compilazione.
Purtroppo no. Il tester rimarrà a thread singolo e senza MQL5 Cloud Network.
Non dimenticate che abbiamo un ottimo inliner in funzione, che scarica un sacco di piccole funzioni, quindi non c'è perdita di velocità.
E nella maggior parte dei casi, le chiamate alle funzioni virtuali tramite vtable sono ottimizzate in chiamate dirette. Questo è uno dei metodi efficaci dell'ottimizzatore. Il che, insieme all'inlining multiplo, permette di sbarazzarsi quasi completamente delle chiamate complesse a più livelli e di far sembrare il codice piatto.
Ahhhh... Ora capisco perché uno dei miei errori più frequenti quando scrivo un programma è "La funzione deve avere un corpo".
È l'inliner che richiede... Mi chiedevo perché pensavo che un'intestazione di funzione fosse sufficiente per compilare un modulo, ma no... Hai bisogno di un corpo...
Questo è un bene.
Ahhhh... Ora capisco perché uno dei miei errori più frequenti quando scrivo un programma è "La funzione deve avere un corpo".
È l'inliner che richiede... Mi chiedevo perché pensavo che un header di funzione fosse sufficiente per compilare un modulo, ma no... Hai bisogno di un corpo...
È corretto, ma non ha niente a che fare con l'ottimizzatore.
Se avete descritto il prototipo di una funzione di classe, il corpo deve esserci. Anche se è vuoto.
Renat, suggerisco che in MT4 dovremmo rendere la visibilità delle posizioni sul controllo del grafico non nei parametri generali del terminale, ma separatamente per ogni grafico (come è stato fatto in MT5).
La mia domanda alla SR su questo argomento è rimasta in sospeso per due mesi.
Renat, suggerisco che in MT4 dovremmo rendere la visibilità delle posizioni sul controllo del grafico non nei parametri generali del terminale, ma separatamente per ogni grafico (come è stato fatto in MT5).
La mia domanda alla SR su questo argomento è rimasta in sospeso per due mesi.