Programmazione asincrona e multithread in MQL - pagina 16
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
Ti ho già scritto che stai cercando di costruire un NS, non hai bisogno di asincronia in questo caso?
Ma state costruendo NS su semplici funzioni di attivazione, quindi non avete riscontrato una mancanza di concorrenza.
Ma quando inizierete a costruire modelli globali di NS, allora capirete la bellezza dell'asincronia.
cattivo esempio - non necessario!
@Roffild ha già scritto nel thread"Nel mondo di oggi, un programmatore deve conoscere diversi linguaggi per scegliere lo strumento giusto per un particolare compito. "
questo è vero!
In MQL non c'è scelta di pacchetti per MQL - solo AlgLib - voglio considerare un esempio, trovato su hubra, prendo e collego C# o Python a MQL - questo è tutto, faccio quello che voglio fare, non porting di codice a MQL
Oggigiorno i linguaggi di programmazione sono interessanti non per le loro caratteristiche, ma per i framework già pronti! - Se in MQL ci saranno nuovi pacchetti MQL, allora ci saranno altri compiti e problemi!
ZS: ancora una volta sulle mie dita, ti stai aggrappando a "l'idea di fx" che è cresciuta dai linguaggi multipiattaforma Python e Java, il sacrificio per la portabilità e la flessibilità del linguaggio era la perdita di prestazioni, ora questi linguaggi sono stati sovradimensionati con diversi modi per aumentare le prestazioni, ma nei linguaggi simili al C gli sviluppatori raggiungono sempre le massime prestazioni e non c'è bisogno (nella maggior parte dei casi) di dividere il compito in thread separati (i compiti client - server non contano, lì il problema è la velocità di scambio dati e questo è un altro specifico)
cattivo esempio - non necessario!
@Roffild ha già scritto nel thread"Nel mondo di oggi, un programmatore deve conoscere diversi linguaggi per scegliere lo strumento giusto per un compito specifico. "
questo è vero!
In MQL non c'è scelta di pacchetti per MQL - solo AlgLib - voglio considerare un esempio, trovato su hubra, prendo e collego C# o Python a MQL - questo è tutto, faccio quello che voglio fare, non porting di codice a MQL
Oggigiorno i linguaggi di programmazione sono interessanti non per le loro caratteristiche, ma per i framework già pronti! - Se in MQL ci saranno nuovi pacchetti MQL, allora ci saranno altri compiti e problemi!
ZS: ancora una volta sulle dita, ti stai aggrappando a "l'idea di fx" che è cresciuta dai linguaggi multipiattaforma Python e Java, il sacrificio per la portabilità e la flessibilità del linguaggio era la perdita di prestazioni, ora questi linguaggi si sono circondati di vari modi per aumentare le prestazioni, ma nei linguaggi C-like gli sviluppatori raggiungono sempre il massimo delle prestazioni e non c'è bisogno (nella maggior parte dei casi) di dividere il compito in thread separati (i compiti client - server non contano, lì il problema è la velocità di scambio dati e questa è un'altra specificità)
Lei ignora costantemente le seguenti cose:
1. La distribuzione di programmi che usano connessioni esterne non può essere fatta attraverso il Mercato.
2. I programmi che usano connessioni esterne richiedono che l'utente sia un "professore" per collegare tutto correttamente. Le istruzioni per l'uso di un tale programma sono un casino.
3. I programmi che usano connessioni esterne sono adatti solo per uso personale, il che limita molto il senso della loro creazione.
4. I programmi per uso personale sono di qualità inferiore a quelli in vendita, perché si può fare tutto da soli... e NON si può essere lo stesso esperto in più lingue contemporaneamente. Alcune lingue si conoscono dalla quinta alla decima lingua e questo influenzerà la qualità del prodotto.
5. Ci sono molti compiti che richiedono l'asincronia e il multi-threading. I programmi MQL non hanno ancora raggiunto questi compiti, ma ciò non significa che non debbano sforzarsi per raggiungerli.
...
Cosa realizza l'asincronia in un singolo flusso.
No, beh, l'asincronia senza multithreading è davvero un'assurdità, avete bisogno di almeno un thread aggiuntivo. Penso che il tuo EventLoop possa essere fatto tramite indicatori caricabili. La comunicazione tra gli indicatori esperti attraverso i socket, per esempio. Un compito è stato creato, l'indicatore è stato agganciato, il compito è stato inviato, l'indicatore ha segnalato l'esecuzione, richiediamo lo stato del compito all'Expert Advisor, cancelliamo l'indicatore. Attraverso stampelle, ma comunque multithreading.
Sì, quell'articolo è molto buono, per una soluzione unica, a pensarci bene, forse si può spremere qualcos'altro da questo approccio.
Ho deciso la direzione del mio problema, grazie ad Andrey per il suggerimento.
Il fatto che abbiate letto un articolo è buono.
Non i thread, cioè le chiamate non bloccanti tramite le funzioni colback, controllate da EventLoop.
Questo raggiunge l'asincronia in un thread.
Come avete fatto a non trovarlo nella documentazione?
Perché non lo leggi?
Lei ignora costantemente le seguenti cose:
Tu ed io abbiamo compiti diversi, non tieni conto che ci sono 2 grandi passi nello scrivere software: lo sviluppo del software e l'implementazione stessa.
Lo sviluppo del software richiede soluzioni già pronte - ci vuole tempo; se durante lo sviluppo si scopre che il software non svolgerà i suoi compiti come previsto, va nella spazzatura. E l'implementazione stessa è un lavoro meccanico per le capacità di una particolare piattaforma.
5. Ci sono molti compiti che richiedono asincronia e multithreading. I programmi MQL non hanno ancora raggiunto questi compiti, ma questo non significa che non debbano sforzarsi per raggiungerli.
Ok, ora andiamo con te:
Rispondere alla domanda: perché ilterminale di trading ne ha bisogno?
Il fatto che abbiate letto un articolo è buono.
Come avete fatto a non trovarlo nella documentazione?
Perché non lo leggi?
Immagina di non trovarlo.
Cercando callback e eventloop non si trova nulla del genere nella documentazione.
Se non ti dispiace, per favore dammi un link senza sarcasmo.
1. Tu ed io abbiamo compiti diversi; non tieni conto che ci sono due grandi fasi nello scrivere software: lo sviluppo del software e l'implementazione.
Lo sviluppo del software richiede soluzioni già pronte - questo richiede tempo; se durante lo sviluppo si scopre che il software non svolgerà i suoi compiti come previsto, va sprecato. E l'implementazione stessa è un lavoro meccanico per le capacità di una particolare piattaforma.
OK, ora andiamo con te:
2. Rispondere alla domanda: perché ilterminale di trading ne ha bisogno?
1. Tutto quello che faccio è lo sviluppo. Appena 6 anni di sviluppo continuo non capisco cosa sia. )) Penso che le soluzioni esterne già pronte, strappate dal contesto di altri programmi o astratte da qualche altro programma, si integrano male nella struttura di un codice altamente specializzato e possono diventare molto disordinate. L'input di lavoro in questo caso è più alto che nello sviluppo della propria soluzione e la qualità finale del codice è inferiore. Per non parlare del potenziale di sviluppo. Queste sono le realtà dello sviluppo. Ma questo è irrilevante per la nostra domanda. In effetti, cosa c'entra questo?
2. Stai facendo la domanda sbagliata. La domanda principale è "Perché l'utente finale ne ha bisogno? Perché l'utente è sempre a corto di funzioni offerte. Pertanto, devono essere aggiunti in modo che non perdano interesse. Se finiamo le possibilità e non possiamo aggiungerne di nuove a causa di limitazioni tecniche, l'utente uscirà. Sono necessarie opportunità per mantenere gli utenti sul terminale e la distribuzione del software è necessaria a questo scopo. Pertanto, i programmi che non possono essere distribuiti non hanno senso per la comunità, indipendentemente dai linguaggi che usano.
Infatti, si guarda solo ai propri bisogni e non si considerano i bisogni degli altri utenti. Tu non fai e non vuoi fare affari in questa comunità, e trasmetti solo la motivazione per fare soldi sul mercato. E puoi fare soldi sul mercato senza alcun software.
cattivo esempio - non necessario!
@Roffild ha già scritto nel thread"Nel mondo di oggi, un programmatore deve conoscere diversi linguaggi per scegliere lo strumento giusto per un compito specifico. "
questo è vero!
In MQL non c'è scelta di pacchetti per MQL - solo AlgLib - voglio considerare un esempio, trovato su hubra, prendo e collego C# o Python a MQL - questo è tutto, faccio quello che voglio fare, non porting di codice a MQL
Oggigiorno i linguaggi di programmazione sono interessanti non per le loro caratteristiche, ma per i framework già pronti! - Se in MQL ci saranno nuovi pacchetti MQL, allora ci saranno altri compiti e problemi!
ZS: ancora una volta sulle dita, ti stai aggrappando all'"idea fissa" che è cresciuta dai linguaggi multipiattaforma Python e Java, il sacrificio per la portabilità e la flessibilità del linguaggio era la perdita di prestazioni, ora questi linguaggi sono diventati circondati da diversi modi di aumentare le prestazioni, ma nei linguaggi simili al C gli sviluppatori raggiungono sempre il massimo delle prestazioni e non c'è bisogno (nella maggior parte dei casi) di dividere il compito in thread separati (i compiti client - server non sono inclusi, lì il problema è la velocità di scambio dati e questa è un'altra specificità)
Igor, a volte ti contraddici.
L'ultima volta hai scritto che la velocità di calcolo di mql è paragonabile a quella di C++
OK, questo è effettivamente vero e molte persone lo sanno.
Ma poi si dà un esempio di collegamento di framework di terze parti per portare i calcoli, come si dice sulle lingue in ritardo.
E voi sostenete la connettività dei pacchetti di terze parti. Quindi stai sacrificando la velocità per un framework standard?
E così, come ha scritto Peter, si perde completamente la portabilità del programma.
Non è una buona soluzione. Per uso personale, sì, ma non per uso di massa.
Immagina di non trovarlo.
La ricerca di callback e eventloop non trova nulla di simile nella documentazione.
Se non ti dispiace, dammi un link senza sarcasmo inutile.
Non devi fare una ricerca, devi leggere tutto. Sono sicuro che ci sono molte sorprese per voi.
Non ci sarà nessun link.
Qui ho aiutato più di una volta persone che hanno almeno provato a fare qualcosa per se stesse.
E cosa avete fatto?
Te ne stai lì a guardare la tua bocca sul forum?
Beh, ti sto aiutando in questo.