Programmazione asincrona e multithread in MQL - pagina 7
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
Beh, neanche io sono, sai, un tipo da fai da te )). È molto probabile che io sia in grado di chiamare funzioni µl da dll, ma il problema sarà probabilmente la necessità di scavare sotto il debugger dopo ogni avvio. Tutto sommato, non è una grande opzione.
Non si tratta di te o di me! Si tratta dell'industria informatica stessa, i metodi di protezione sono stati inventati da tempo e vengono costantemente migliorati, c'è chi fa la protezione e chi la "testa"
E il mio imho, se vedete un altro articolo su un altro hack per PlayStation / XBox, allora qualcuno ne ha bisogno! - Mayakovsky )))) - questa è una strategia di marketing di un gigante IT e non un altro hacker intelligente che è riuscito a trovare una vulnerabilità - sì, ci sono bug nel software, le vulnerabilità accadono, ma ci sono anche strategie di marketing che aumentano l'interesse nel software
;)
Imho, tu sopravvaluti la complessità del compito (strappare mcl dalla dll), ma la soluzione è complicata e scomoda (perché sedersi nel debugger dopo ogni esecuzione?). Molto più elegante - pensate a un protocollo per lo scambio tra il servizio nel terminale e il programma di terze parti via sockets, scrivete la parte C e mkl, e mettetelo nell'accesso libero e aperto. Questo è tutto, non c'è nemmeno bisogno di rompere nulla.
non è chiaro cosa farà questo?
Come dicono gli sviluppatori, non è possibile andare oltre la "sandbox MQL" per ogni programma, quindi cosa vi porterà attraverso le prese a TCP?
non potrete arrivare a un altro programma MQL senza la modifica del codice sorgente, allo stesso modo in cui abbiamo iniziato - non sarete in grado di chiamare qualsiasi funzione MQL da una DLL.
o stiamo parlando del controllo remoto di un programma MQL? - Questo non è mai stato un problema, sviluppiamo il nostro protocollo di scambio e controlliamo quello che possiamo.
Si tratta di "fare una parvenza di API", universale. Agganciare una lib a un programma trasversale e ottenere dati/inviare richieste. E sarà maturo, senza sandbox e "preoccupandosi" della mia sicurezza. E non c'è bisogno di gestire nulla - solo dati e richieste. Presto questa struttura sarà riempita con tutti i tipi di carne - come i grafici con l'analisi tecnica.
Ma il pubblico qui non è lo stesso - i venditori e gli acquirenti del mercato.
Igor Makanu:
I programmi MQL con dll non sono popolari in rete, casomai... Forse non l'hai fatto apposta, ma il tuo computer è malato di qualcosa e insieme alla tua dll stai mandando un mucchio di virus al PC del tuo utente... In generale, gli sviluppatori hanno promesso la massima protezione per l'utente finale, cioè il commerciante.
È tutto un Windows di merda, anche se sembra che l'abbiano ripulito.
Non ho paura di eseguire qualsiasi eseguibile sul mio Linux - eseguendolo senza diritti di amministratore questo software non può nemmeno fare qualcosa di sbagliato. Ho dimenticato i virus insieme al virus.
È tutto il windup incasinato, anche se sembra che l'abbiano anche ripulito.
Non ho paura di eseguire qualsiasi applicazione sul mio linux
Capito)))
Se il linguaggio mql implementa la funzionalità per lavorare con codice asincrono, allora possiamo tradurre il lavoro degli indicatori fuori dalla scatola in modalità asincrona e liberarci del problema del threading.
Dopo aver risolto il problema del multi-threading degli indicatori, potete tranquillamente implementare i grafici a tick. Tutta la catena è interconnessa.
La modalità asincrona darà un nuovo impulso allo sviluppo della scrittura di programmi veloci. Risolverà il problema dell'espansione ai grafici in tick.
L'asincronia darà un nuovo impulso allo sviluppo della scrittura di programmi veloci.
Date le qualifiche delle persone qui, questo è più un modo quasi garantito di darsi la zappa sui piedi.
E coloro che hanno davvero bisogno coscientemente dell'asincronia e del multithreading per se stessi non hanno problemi a implementarli con i mezzi disponibili.
Date le competenze delle persone qui, questo è un modo quasi garantito per darsi la zappa sui piedi.
E coloro che hanno davvero bisogno coscientemente dell'asincronia e del multithreading per se stessi non hanno problemi ad implementarlo con i mezzi disponibili.
Che tali individui si sparino subito in testa. Non è un problema degli sviluppatori e del loro prodotto...
Imparare e capire il principio della modalità asincrona è come due dita sull'asfalto, non sono flussi. E se è difficile, non c'è niente da fare.
Sembra che la differenza speciale tra asincronia e multithreading provenga dalla stessa area del problema della differenza puntatore/riferimento che affligge alcune persone.
L'asincronia è implementata attraverso un thread separato e non è così importante se questo processo è fornito dal processore o da qualsiasi altro dispositivo. La creazione di un processo implica la sua asincronia perché esiste in parallelo.
Ho letto i partecipanti intelligenti e mi chiedo...
Che senso hanno tutti questi espedienti?
Quando in MQL il multi-threading sarebbe così terribilmente necessario? Per me, l'unico uso sarebbe il test delle strategie, che è implementato nel modo standard.
L'idea è che potrebbe avere senso eseguire diverse WebRequest, ma non credo che il multi-threading sia affatto necessario.
Quali compiti richiedono il multithreading in primo luogo?
George, il punto di qualsiasi cosa può sempre essere deragliato. E non c'è niente che possa contrastare questo approccio. E perché una persona dovrebbe avere bisogno di soldi se sta per morire comunque? Tutti moriranno comunque, perché abbiamo bisogno del mercato, dell'algotrading e così via?
Avere una struttura multi-threading interna in MQL sarebbe molto bello. Capite, questo è un terreno di prova creativo per molti. La domanda "perché?" non è sempre appropriata.