Mt4 Fine del supporto. - pagina 11
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
Vladimir:
Forse per organizzare l'interfaccia con l'utente? Questo è dove un sacco di variazioni sulla OOP sono inventate, una libreria di componenti visivi in Delphi. Così, Expert Advisors e script sono progettati per sostituire gli esseri umani sul computer, questa interfaccia contraddice direttamente il loro scopo, non è necessario. Cioè, è in mezzo ai piedi. Proprio come gli oggetti inutili in un coltellino. O una chiodatrice sull'estremità del manico d'acciaio di un martello universale - non solo graffia, ma sposta anche il centro di gravità dal percussore al manico.
Non sono d'accordo con te su questo punto particolare.
Un'interfaccia grafica può essere necessaria per gli algotraders che capiscono che un EA completamente automatico è, di gran lunga, molto meno efficace di uno semi-automatico. Combinare il trading automatico e manuale può essere più professionale e redditizio dal punto di vista del trading. Quando la gente se ne renderà conto, i loro robot avranno sicuramente bisogno di un'interfaccia.
1. graph_id può essere letto da una persona che parla russo più velocemente di m_chart_id.
2. Se ci sono centinaia di variabili in un programma, il russo fornisce un supporto indispensabile.
Tutto questo può essere testato in un esperimento.
La velocità di lettura e comprensione del codice nella lingua madre sarà sempre più veloce e la memorizzazione sarà migliore.
Hai solo bisogno di capire le regole di denominazione delle variabili in russo. Invece di "variable_to_store_general_profit_position, solo: general_profit.
Se ci sono centinaia di variabili in un programma, la maggior parte di esse può probabilmente essere combinata da strutture. Inoltre, non dimenticate di usare le funzioni.
Molte variabili non hanno alcun senso, perché sono contatori, magazzini temporanei di dati intermedi, e sono usate dietro un mucchio di parentesi. E soprattutto, dietro a tutte le parentesi possiamo di nuovo usare le stesse variabili, ma di nuovo tra parentesi {....}
O inizialmente scrivere in OOP.
Mi sembra che l'essenza del suo rifiuto dell'OOP stia in questo. Potrei sbagliarmi, naturalmente, ma di solito sento la gente.
Secondo me, il problema della maggior parte delle non-OBO è una resistenza interna alla "limitazione dei diritti legali".
Un programmatore della vecchia scuola è abituato ad avere pieno accesso a qualsiasi dato, qualsiasi blocco, qualsiasi entità del programma in qualsiasi momento. E l'approccio OOP implica il contrario - la massima limitazione dei diritti, quando si ha accesso a una parte molto piccola dei dati e delle azioni del programma.
Per quanto mi ricordo, non mi piaceva molto. Nei primi giorni di Windows, ricordo che ero molto disgustato dall'accesso protetto alla memoria - non posso accedere all'indirizzo che mi piace, e allora cosa succede se è nel kernel del sistema? Potrei anche volerlo leggere da un programma o cambiarlo del tutto! Ho anche programmato un controller di accesso diretto alla memoria, che avrebbe inviato dati alla "zona consentita" dalla "zona proibita", aggirando le restrizioni del sistema.
Ma, col tempo, ho davvero apprezzato tutte queste restrizioni. Gli accessi "non necessari" possono sempre trasformarsi in errori. Quindi è molto saggio spostare il lavoro di controllo dell'accesso - al compilatore.Limitare l'accesso qui risulta essere "infallibile", non "violazione dei vostri diritti". Se avete bisogno di un accesso che non avete, significa solo che avete progettato male il sistema - avreste dovuto prevederlo se ne avevate bisogno.
E ora - al contrario, limito sempre l'accesso il più possibile. In qualsiasi punto ci dovrebbe essere l'accesso solo a quelle entità che sono necessarie. Tutte le altre entità devono essere inaccessibili. Questo vi protegge da errori con l'accesso a posti che non dovreste, e vi abitua anche a una certa sequenza di sviluppo del sistema, dove ogni operazione viene eseguita in un posto, e nessun altro posto è interessato.
Per esempio, odio gli inludi sotto forma di librerie, solo perché non so cosa ci mettono e come può aiutarmi, è più facile scrivere una dozzina di funzioni in più
simile a quello a cui sono abituato con Re-Tag Konow.
E perché?
Una stessa funzione è richiesta in molti posti - perché copiare le funzioni quando si può avere tutto nelle librerie, e non ingombrare il codice principale con blocchi inutili?
E perché?
Una stessa funzione è richiesta in molti posti - perché copiare le funzioni quando si può avere tutto nelle librerie e non ingombrare il codice principale con blocchi inutili?
Sei bravo a trovare argomenti, Nikolai).
Anche la nonna può assimilare tutto senza problemi. È solo che inconsciamente non vuole che nessun gingillo trascini la sua mente assestata in un ciclo di informazioni inutili. Giustamente).
Peter, così si scopre che sei una nonna.
Ciao
Potrei essere in grado di ottenere un po' di aiuto qui. Ho una domanda per gli sviluppatori di MT4. Dove può essere espresso. Se su questo forum, allora in quale thread? O da qualche altra parte? Se lo sai, per favore dimmelo.
Non sono d'accordo con te su questo punto particolare.
Un'interfaccia grafica può essere necessaria per gli algotraders che si rendono conto che un EA completamente automatizzato è, di gran lunga, molto meno efficace di uno semi-automatico. Combinare il trading automatico e manuale può essere più professionale e redditizio dal punto di vista del trading. Quando la gente se ne renderà conto, i loro robot avranno sicuramente bisogno di un'interfaccia.
Tu sostieni pienamente la persona che dice che mql dovrebbe avere solo funzioni di accesso al server, e tutto il resto tramite stampelle dovrebbe essere programmato da strumenti di sviluppo di terze parti. Non deviate dalla linea del partito. Sii coerente - scarica tutti i tuoi sviluppi su mql e fai un ponte - in studio per esempio - o dovunque andrai a scrivere le tue tele... Poi riferisci della tua prossima vittoria sul mulino.
Per esempio, odio gli inludi sotto forma di librerie, solo perché non so cosa ci mettono e come può aiutarmi, è più facile scrivere una dozzina di funzioni in più
simile a quello di Retrog Konow.
Beh, la legge della conservazione dell'energia: perché decompilare la libreria e capirla se tutto funziona senza?
P.S.
Hai visto il mio top sull'alce?
Quando i vostri codici iniziano a traboccare 10, 20, 30, ... , 100 mila linee, poi tornate e ditemi come fate a copiare i vostri codici in tale volume.
Secondo me, il problema della maggior parte delle non-OBO è una resistenza interna alla "limitazione dei diritti legali".
Un programmatore della vecchia scuola è abituato ad avere pieno accesso a qualsiasi dato, qualsiasi blocco, qualsiasi entità del programma in qualsiasi momento. E l'approccio OOP implica il contrario - la massima limitazione dei diritti, quando si ha accesso a una parte molto piccola dei dati e delle azioni del programma.
Per quanto mi ricordo, non mi piaceva molto. Nei primi giorni di Windows, ricordo che ero molto disgustato dall'accesso protetto alla memoria - non posso accedere all'indirizzo che mi piace, e allora cosa succede se è nel kernel del sistema? Potrei anche volerlo leggere da un programma o cambiarlo del tutto! Ho anche programmato un controller di accesso diretto alla memoria, che avrebbe inviato dati all'"area consentita" dall'"area proibita", aggirando le restrizioni del sistema.
Ma, col tempo, ho davvero apprezzato tutte queste restrizioni. Gli accessi "non necessari" possono sempre trasformarsi in errori. Quindi è molto saggio spostare il lavoro di controllo dell'accesso - al compilatore.Limitare l'accesso qui risulta essere "infallibile", non "violazione dei vostri diritti". Se avete bisogno di un accesso che non avete, significa solo che avete progettato male il sistema - avreste dovuto prevederlo se ne avevate bisogno.
E ora - al contrario, limito sempre l'accesso il più possibile. In qualsiasi momento, solo le entità a cui è necessario accedere dovrebbero essere disponibili. Tutti gli altri oggetti devono essere inaccessibili. Questo vi protegge da errori con l'accesso a posti che non dovreste, e vi abitua anche a una certa sequenza di sviluppo del sistema, dove ogni operazione viene eseguita in un posto, e nessun altro posto è interessato.
Hai dato un buon esempio di ciò che l'OOP può respingere.
Nel mio caso è stato un po' diverso. Ho iniziato ad imparare l'OOP, ma ad un certo punto ho smesso di vedere qualsiasi beneficio pratico nel suo utilizzo. Fino ad oggi, questo non è cambiato. Tutto perché ho formato il mio approccio, che ha spinto OOP fuori dalla mia pratica.
Questa affermazione - che la limitazione dell'accesso è una protezione necessaria che salva dagli errori - è qualcosa che non riesco proprio a capire. Se i nomi delle variabili coincidono in diverse parti del programma, naturalmente sì. Ma se c'è una memoria globale comune di tutte le variabili globali principali in un array, non c'è bisogno di restrizioni e non ci sarà confusione.