Programmation asynchrone et multithread dans MQL - page 12
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
(Parole d'idiot, désolé. ))
Excusez-moi qui ? Des gens que je ne connais pas ? ))) - c'est un forum - wiki à la rescousse... c'est une plateforme où chacun exprime/défend ses opinions, ni plus ni moins - et au cours de la communication, les aspects techniques et/ou l'échange d'expériences sont clarifiés, comme appliqué à cette ressource !
ZS :
à votre avis, OK, vous êtes un développeur de "la bonne fonctionnalité graphique" - oui c'est nécessaire !
- Mais vous devez être capable de créer soit une fonctionnalité familière aux autres programmeurs (malheureusement, tout le monde apprend de la même littérature et utilise ensuite la fonctionnalité offerte par les géants de l'informatique - c'est-à-dire la fonctionnalité familière, compréhensible et accessible)
- ou devez-vous fournir un progiciel d'analyse puissant, enveloppé dans une interface graphique, qui vous permette d'étudier/modéliser les données - en êtes-vous capable ? - Pouvez-vous rivaliser avec, par exemple, le paquet R ?
;)
Pour chercher, pour développer un TS (certains n'ont même pas besoin d'un TS, George par exemple se moque de ce qu'est un TS), MT4 suffit. De quoi parle-t-on alors ? Chacun a ses propres besoins. L'un vit bien dans un monastère, et l'autre veut parcourir le monde. En bref, cette conversation ne porte sur rien. C'est comme si je demandais à un artiste pourquoi il devrait peindre un tableau s'il peut simplement prendre une photo stupide de la nature. C'est une conversation stupide, désolé. ))
Le même avis, hélas, m'est venu, en parlant ici avec les "experts" locaux ((
Si les développeurs créent l'EventLoop pour l'écriture de code asynchrone, respect et admiration, comme on dit.
Et le terminal sera le leader dans son segment de produit, faisant ainsi gagner à tous, dans tous les sens du terme, tous les autres développeurs de terminaux du monde.
Ils savent exactement où se trouvent les problèmes, qui nécessitent une exécution asynchrone, mais pour une raison quelconque, les mêmes indicateurs sont toujours exécutés dans un seul fil.
D'autres utilisateurs supposent que c'est pour cette raison qu'ils n'implémentent pas les graphiques en tableaux de tics - ils craignent prétendument que les utilisateurs attachent beaucoup d'indicateurs à un graphique en tableaux de tics.
Et ce n'est que la partie visible, donc écouter les experts locaux n'est pas toujours utile, hélas, ils sont juste coincés dans un seul fil alors que le monde est déjà multi-fil depuis longtemps.
Excusez-moi qui ? Des gens que je ne connais pas ? ))) - c'est un forum - wiki à la rescousse... c'est une plateforme où chacun exprime/défend ses opinions, ni plus ni moins - et au cours de la communication, les aspects techniques et/ou l'échange d'expériences sont clarifiés, comme appliqué à cette ressource !
ZS :
à votre avis, OK, vous êtes un développeur de "la bonne fonctionnalité graphique" - oui c'est nécessaire !
- Mais vous devez être capable de créer soit une fonctionnalité familière aux autres programmeurs (malheureusement, tout le monde apprend de la même littérature et utilise ensuite la fonctionnalité offerte par les géants de l'informatique - c'est-à-dire la fonctionnalité familière, compréhensible et accessible)
- ou devez-vous fournir un puissant progiciel d'analyse, enveloppé dans une interface graphique, qui vous permette d'étudier/modéliser les données - en êtes-vous capable ? - Pouvez-vous rivaliser avec, par exemple, le paquet R ?
;)
Je suis arrivé à la même opinion, hélas, après avoir parlé aux "experts" locaux ici ((.
Si les développeurs font d'EventLoop un outil d'écriture de code asynchrone, alors bravo et respect comme on dit.
Et le terminal sera le leader dans son segment de produit, faisant de tous, dans tous les sens du terme, tous les autres développements mondiaux de terminaux.
Ils savent exactement où se trouvent les problèmes nécessitant une exécution asynchrone, mais pour une raison quelconque, les mêmes indicateurs sont toujours exécutés dans un seul fil.
D'autres utilisateurs supposent que c'est pour cette raison qu'ils ne mettent pas en œuvre les graphiques à tic-tac - ils ont peur des conséquences négatives, lorsque les utilisateurs attachent un tas d'indicateurs au graphique à tic-tac.
Et ce n'est que la partie visible, donc écouter les experts locaux n'est pas toujours utile, hélas, ils sont juste coincés dans un seul fil alors que le monde est déjà multi-fil depuis longtemps.
J'essaie de comprendre votre logique. Je veux dire que si je ne suis pas capable de rivaliser avec le paquet R, alors je n'ai pas besoin du multithreading ? Quel est le lien ici. Essayez-vous de prouver que si vous n'en avez pas besoin, personne d'autre ne devrait en avoir besoin ? Je le répète : chacun a des tâches différentes. J'ai le mien, tu as le tien.
La logique est simple - l'utilisateur final, si vous avez une demande pour au moins 1-2 utilisateurs par mois, mon respect - vous avez trouvé votre niche !
La logique est simple - l'utilisateur final, si vous avez une demande pour au moins 1-2 utilisateurs par mois, mon respect - vous avez trouvé votre niche !
Le même avis m'est hélas parvenu, et j'ai communiqué ici avec les "experts" locaux ((
Si les développeurs utilisent EventLoop pour écrire du code asynchrone, respectez-les comme on dit.
Et le terminal sera le leader dans son segment de produit, rendant tous, dans tous les sens du terme, tous les autres développements de terminaux mondiaux.
Ils savent exactement où se trouvent les problèmes nécessitant une exécution asynchrone, mais pour une raison quelconque, les mêmes indicateurs sont toujours exécutés dans un seul fil.
D'autres utilisateurs supposent que c'est pour cette raison qu'ils ne mettent pas en œuvre les graphiques à tic-tac - ils ont peur des conséquences négatives, lorsque les utilisateurs attachent un tas d'indicateurs au graphique à tic-tac.
Et ce n'est que la partie visible, donc écouter les experts locaux n'est pas toujours utile, hélas, ils sont juste coincés dans un seul fil alors que le monde est déjà multi-fil depuis longtemps.
"experts" ? - Tu n'as rien à dire, fourre ton imho... Vous avez une grande communauté MQL sur ce site avec des professionnels dans différents domaines, malheureusement, vous n'avez montré aucune de vos connaissances qui seraient utiles à la communauté, vous pouvez encore me blâmer pour tout ce que vous voulez - "vous êtes l'expert ! "
Les développeurs feront l'affaire ? - Vous ne pouvez même pas expliquer POURQUOI c'est nécessaire, n'est-ce pas ? )))
Quel est l'objectif de MetaQoutes ? - le but, comme toute entreprise informatique de faire du profit ! Je ne sais pas pourquoi, MetaQoutes est très sérieux dans la promotion de ses services, beaucoup de travail est fait pour populariser le trading algorithmique, pour donner du matériel analytique, pour créer une communauté en ligne... ce genre d'action caritative n'est le fait que de quelques sociétés informatiques, généralement les géants du secteur.
Ainsi, l'entreprise consacre ses ressources à quelque chose qui, à l'avenir (pas sûr), fera des bénéfices. .... et puis, voilà... un utilisateur arrive qui a besoin d'adapter le concept de Python ou Java retardé à MQl..... Tu ne trouves pas ça drôle ? - Quel âge avez-vous ? ))))
Nous le saurons bien assez tôt. Nous ne le savons pas encore.
Je vous respecte, la persistance est souvent le seul moyen de trouver sa niche dans cette vie ! Bonne chance dans ce dur labeur !
...
S'ils ajoutent le multithreading, cela vous fera-t-il sentir plus mal ? Ils ont déjà ajouté beaucoup de choses à MQL, et c'est une chose vraiment utile. Mais son utilité ne peut être comprise que par une personne qui écrit des programmes très complexes et encombrants en MQL. Si vous ne comprenez pas à quoi sert le multithreading, cela signifie que vous n'écrivez pas de tels programmes. Quand tu le feras, tu comprendras. C'est très simple. ))
...
Je respecte le fait que la persistance est souvent le seul moyen de trouver sa niche dans la vie ! Bonne chance avec ce travail acharné !
Merci. Pareil pour vous !
Je suis arrivé à la même conclusion, hélas, après avoir parlé aux "experts" locaux ici ((
Si les développeurs font d'EventLoop un outil d'écriture de code asynchrone, alors bravo et respect comme on dit.
Et le terminal sera le leader dans son segment de produit, rendant tous, dans tous les sens du terme, tous les autres développements de terminaux mondiaux.
Ils savent exactement où se trouvent les problèmes nécessitant une exécution asynchrone, mais pour une raison quelconque, les mêmes indicateurs sont toujours exécutés dans un seul thread.
D'autres utilisateurs supposent que c'est pour cette raison qu'ils ne mettent pas en œuvre les graphiques à tic-tac - ils ont peur des conséquences négatives, lorsque les utilisateurs attachent un tas d'indicateurs au graphique à tic-tac.
Et ce n'est que la partie visible, donc écouter les experts locaux n'est pas toujours utile, hélas, ils sont juste coincés dans un seul fil alors que le monde est déjà multi-fil depuis longtemps.
Vous exigez une exécution asynchrone des requêtes, mais vous citez le multithreading en exemple... Je t'ai encouragé à le découvrir, mais tu ne l'as jamais fait.
Je vous ai donné une solution à votre problème exact ici : https://www.mql5.com/ru/forum/318593/page4#comment_12568119.
Mais je suis sûr que vous n'avez même pas étudié le sujet.
Il me semble que si on vous donne une file d'attente asynchrone, vous demanderez toujours le multithreading... Essayez au moins de comprendre les notions de OVERLAPPED et d'événements pour commencer, n'êtes-vous pas en train de demander à WinAPI d'entrer dans votre code).
Si vous introduisez le multithreading dans le terminal, il s'enterrera lui-même des programmeurs malheureux, plus vite que la vitesse de la lumière.
Les programmeurs cherchent des solutions aux problèmes, et non pas à demander au cadre de changer pour s'adapter à leur ignorance.