Programmazione asincrona e multithread in MQL - pagina 5
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
Il problema principale non è nel "...devo ancora imparare".
Il problema principale è che più sono tutti questi avvertimenti, maggiore è il pericolo di ottenere errori complicati, che non sono facili da calcolare.
E tutto questo è un ulteriore mal di testa per gli sviluppatori.
Inoltre - è bene valutare se molte persone hanno davvero bisogno di questo multithreading?
Il problema principale non è "...ancora da imparare".
Il problema principale è che più sono tutti questi espedienti, maggiore è il pericolo di ottenere errori complicati, che sono molto difficili da calcolare.
Tutto questo è un ulteriore mal di testa per gli sviluppatori.
Inoltre - è bene valutare se molte persone hanno davvero bisogno di questo multithreading?
Bene, una scrofa e un cavallo, allora, e via... verso l'alba del mattino...
Peccato che mql non abbia questa funzione,
Ladirezione suggerirà di sviluppare una funzione standard mql per la programmazione asincrona,
dato che ci sono problemi con i fili e soprattutto con la sicurezza.
Per la modalità asincrona penso che non ci siano ostacoli alla sicurezza.
Ieri ero a casa di mia suocera, stanno rinnovando le pareti, state facendo lo stesso? - Aprite le finestre, ventilate le stanze!
Non c'è niente in mezzo! Il compito era quello di usare WinAPI puro. Senza alcun dll fatto in casa!
Il topic è stato creato per discutere di problemi di programmazione multithreaded mql. Hai una sorta di spirito negativo oggi, che tipo di inondazione nel topic, che ho creato io stesso?
Perché WinAPI? Lasciate che vi dica un segreto, CLR è anche "puro Windows", il supporto nativo per le librerie .NET con importazione di funzioni "intelligenti" è stato aggiunto un anno fa, conoscete WinAPI, ma non potete creare un thread in .NET? )))))
La prego di astenersi da tali commenti.
Allora, un aratro e un cavallo, e avanti... verso l'alba del mattino...
Dimitri, hai provato a coltivare e raccogliere con un aratro e un cavallo?
Ci sono altrettante sottigliezze e opportunità di errore. Ma costa molto di più se il raccolto muore e si fa la fame...
Ci sono problemi ovunque, e bisogna misurare il beneficio rispetto allo sforzo richiesto. In particolare, con questo multithreading, non vedo dove sia così direttamente necessario.
Non ho solo suggerito all'autore di scrivere il suo primo programma in pura WinAPIhttps://www.mql5.com/ru/forum/318593/page2#comment_12565043.
ci sono molte informazioni su questo argomento in rete - prima scrivete usando i file header pronti (windows.h e così via), poi rimuovete questi file header e avvicinatevi alla tanto desiderata WinAPI pura = un grosso pezzo di codice che può registrare processo e finestra, che può ricevere eventi e gestirli.... e sarà solo una banale finestra che non può fare nulla di utile, ma capirà quanto lavoro è necessario fare usando WinAPI
Ho provato circa 15 anni fa (non ricordo esattamente, ricordo che c'era una connessione dial-up) e in questo modo qualsiasi "sono un ingegnere del software da mia madre" dovrebbe passare per sbarazzarsi delle domande e del desiderio di dare consigli ai programmatori di sistema - sviluppatori di compilatori
"avendo preso questa strada", sarà chiaro subito un lavoro colossale di centinaia di programmatori di sistema che scrivono compilatori e librerie per loro, sarà chiaro perché la velocità è stata data una comoda funzionalità utente, in modo che qualsiasi programmatore di applicazioni possa leggere la guida e "in 2 clic" ottenere il risultato desiderato
SZZ: in generale, la mancanza di esperienza, conoscenze e competenze ha causato un'altra distorsione cognitiva ))))
Il problema principale non è "...ancora da imparare".
Il problema principale è che più sono tutti questi espedienti, maggiore è il pericolo di ottenere errori complicati, che sono molto difficili da calcolare.
Tutto questo è un ulteriore mal di testa per gli sviluppatori.
Inoltre - è bene valutare - quanti hanno davvero bisogno di questo multithreading?
Dimitri, hai provato a coltivare e raccogliere i raccolti con un aratro e un cavallo?
Ci sono altrettante sottigliezze e opportunità di errore. Ma costa molto di più se il raccolto muore e si fa la fame...
Ci sono problemi ovunque, e bisogna bilanciare il beneficio ottenuto e lo sforzo speso. In particolare, con questo multithreading, non vedo dove sia così direttamente necessario.
Cos'è un aratro e un cavallo? La solita pala.
Se vogliamo essere seri e maturi, il primo compito che sarebbe utile spostare in un thread separato per il lavoro asincrono è WebRequest, ma in generale è Ok, si può vivere anche con questo.
Il secondo compito è la formazione delle reti neurali, l'auto-ottimizzazione integrata in Expert Advisor. Se fosse possibile creare facilmente dei thread da Expert Advisor, questo argomento avrebbe un grande impulso di vita.
Se siamo seri e maturi, il primo compito che sarebbe utile mettere in un thread separato per il lavoro asincrono è WebRequest, ma in generale va bene così e possiamo vivere con questo.
Il secondo compito è la formazione delle reti neurali, l'auto-ottimizzazione integrata in Expert Advisor. Se ci fosse la possibilità di creare facilmente dei thread da un Expert Advisor, questo argomento avrebbe una bella iniezione di vita.
Solo in MQL, entrambi i compiti sono risolti lanciando automaticamente l'Expert Advisor.
Non ho solo suggerito all'autore di scrivere il suo primo programma in pura WinAPIhttps://www.mql5.com/ru/forum/318593/page2#comment_12565043.
ci sono molte informazioni su questo argomento in rete - prima scrivete usando i file header pronti (windows.h e così via), poi rimuovete questi file header e avvicinatevi alla tanto desiderata WinAPI pura = un grosso pezzo di codice che può registrare processo e finestra, che può ricevere eventi e gestirli.... e sarà solo una banale finestra che non può fare nulla di utile, ma capirà quanto lavoro è necessario fare usando WinAPI
Ho provato circa 15 anni fa (non ricordo esattamente, ricordo che c'era una connessione dial-up) e in questo modo qualsiasi "sono un ingegnere del software da mia madre" dovrebbe passare per sbarazzarsi delle domande e del desiderio di dare consigli ai programmatori di sistema - sviluppatori di compilatori
"avendo preso questa strada", sarà chiaro subito un lavoro colossale di centinaia di programmatori di sistema che scrivono compilatori e librerie per loro, sarà chiaro perché la velocità è stata data una comoda funzionalità utente, in modo che qualsiasi programmatore di applicazioni possa leggere la guida e "in 2 clic" ottenere il risultato desiderato
ZS: in generale, la mancanza di esperienza, conoscenza e abilità ha causato un'altra distorsione cognitiva ))))
Igor, non tutti come te hanno una laurea in programmazione. Dove vi hanno insegnato i vostri insegnanti! Ecco perché le qualifiche sono fuori questione.
Per questo motivo l'idea di WinAPI pura è sfocata, ho supposto che sarà più semplice di come l'hai descritta.
Ero un totale estraneo alla programmazione, ed è stato solo grazie a mql che ho iniziato a imparare il C/C++ senza insegnanti e consigli!
Ma come potete vedere, ho raggiunto le esigenze asincrone per conto mio. Sì, forse non so qualcosa, ma sto imparando tutto ciò di cui ho bisogno.
Sì, non conosco la tecnologia .NET e non voglio, sono stufo di C#, ognuno ha la sua portabilità dei linguaggi.
Dove mi hai visto dare consigli agli sviluppatori? È stato fatto un suggerimento per aggiungere a mql un insieme di funzioni standard per lavorare con il codice asincrono.
Questa è una proposta sensata, non so perché hai reagito così negativamente ad essa... O forse il tuo modo di parlare è sempre così?
Se voi non avete bisogno di tale funzionalità, altri utenti sì. È come con l'OOP, non tutti lo usano, ma c'è. L'asincronia sembra essere presente in molti linguaggi ora, ma non in mql.
In che modo mql è peggio di altri linguaggi, che è privo di metodi asincroni? La questione dei thread è chiusa, mentre l'asincronia è implementata out of the box.
Igor, non tutti come te hanno una laurea in programmazione. Dove vi hanno insegnato i vostri insegnanti! Ecco perché la qualificazione è fuori questione.
Per questo motivo l'idea di WinAPI pura è sfocata, ho supposto che sarà più semplice di come l'hai descritta.
Non avevo alcuna familiarità con la programmazione prima, e solo grazie a mql ho iniziato a imparare il C/C++ senza insegnanti e suggerimenti!
Ma, come potete vedere, ho raggiunto le esigenze asincrone per conto mio. Sì, forse non so qualcosa, ma sto imparando tutto ciò di cui ho bisogno.
Sì, non conosco la tecnologia .NET, e non voglio, sono stufo di C#, ognuno ha la sua portabilità dei linguaggi.
Dove mi hai visto dare consigli agli sviluppatori? È stata fatta una proposta per aggiungere a mql un insieme di funzioni standard per lavorare con il codice asincrono.
Questa è una proposta sensata, non so perché hai reagito così negativamente ad essa... O forse il tuo modo di parlare è sempre così?
Se tu non hai bisogno di questa funzionalità, altri utenti sì. Credo che tutti i linguaggi ora abbiano l'asincronia, ma mql no.
In che modo mql è peggio di altri linguaggi, che è privo di metodi asincroni? Bene, la questione dei thread è chiusa, ma l'asincronia è fattibile.
In MQL5 c'è l'asincronia, per esempio,OrderSendAsync.
Per quanto riguarda l'interazione con la rete o il file system - usate WinAPI, ho scritto la soluzione sopra. Penso che ci sia tutto per questo. Potete leggere su come usare questi metodi sul sito di Microsoft. Cos'altro non è stato rivelato?)