Domande su OOP in MQL5 - pagina 66
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
Ecco la risposta al perché:
Nel rettangolo rosso - aggiunta una chiamata aGetMicrosecondCount(), in quello blu - una in più. Ecco perché è quasi uguale.
Perché osi mostrarmi il codice? Senza il codice, potete ficcare le vostre foto a tempo dove non batte il sole.
Ops. Con azioni identiche, c'era solo il 30% di differenza.
Forse sono le classi che creano l'overhead? Naturalmente, il compilatore dovrebbe in ogni caso inlineare tutto e tagliare le cose non necessarie. Ha senso farlo notare agli sviluppatori.
Ha funzionato. La struttura ha lavorato alla stessa velocità della funzione e della macro. Ma la classe... molto indietro.
Ha funzionato. La struttura ha lavorato alla stessa velocità della funzione e della macro. Ma la classe... molto indietro.
Ho dato consigli su come accedere a metodi/campi privati in SB e ho raccolto io stesso questo gancio sul forum, non ricordo chi l'ha suggerito.
Sono stato sorpreso di scoprire che stavo dando consigli come al solito senza attenersi alla terminologia, non era un gancio ma un anti-pattern Pubblico Morozovhttp://blog.kislenko.net/show.php?id=1775
)))
Ho dato consigli su come accedere a metodi/campi privati in SB e ho raccolto io stesso questo gancio sul forum, non ricordo chi l'ha suggerito.
Sono stato sorpreso di scoprire che stavo dando consigli come al solito senza attenersi alla terminologia, non era un gancioma un anti-pattern Pubblico Morozovhttp://blog.kislenko.net/show.php?id=1775
)))
Ecco che hai dato un barile di miele ai negazionisti dei modelli e agli amanti di OO :-) Un modello per ottenere ciò che è nascosto da considerazioni di design :-)
Qualcuno (qualcuno degli attuali mostri di OO/C++), abbastanza ragionevolmente ha detto che il punto critico dell'OO è che la classe base deve fornire interfacce sufficienti per tutte le varianti discendenti (praticamente avere setters-getters disponibili per tutti i campi, o all-in-one),
e i discendenti non possono creare funzioni virtuali al di fuori del protocollo padre, solo allora arriverà la felicità universale. Allora STL+boost generalizzato risparmia davvero, i test sono utili e riutilizzabili. Ma diventa un sacco di classi, perché invece di nuove funzioni virtuali agiscono tutti i tipi di proxy.
Qui avete dato un barile di miele ai negatori di modelli e agli amanti di OO :-) Un modello per ottenere ciò che è nascosto da considerazioni di design :-)
Qualcuno (qualcuno dei mostri attuali di OO/C++), abbastanza ragionevolmente ha detto che il punto critico di OO è che la classe base deve fornire interfacce sufficienti per tutte le varianti discendenti (praticamente avere setters-getters disponibili per tutti i campi, o all-in-one),
e i discendenti non possono creare funzioni virtuali al di fuori del protocollo genitore, solo allora arriverà la felicità universale. Allora STL+boost generalizzato risparmia davvero, i test sono utili e riutilizzabili. Ma diventa un sacco di classi, perché tutti i tipi di proxy agiscono al posto di nuove funzioni virtuali.
Cosa c'entrano i pattern e gli amanti dell'OO?
Qualcuno (qualcuno degli attuali mostri OO/C++), abbastanza sensibilmente ha detto che il punto critico dell'OO è che la classe base deve fornire interfacce sufficienti per tutte le varianti dei discendenti (praticamente avere setter-getters disponibili per tutti i campi, o all-in-a-blank)