Programmation asynchrone et multithread dans MQL - page 16
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
Je vous ai déjà écrit, vous essayez de construire un NS, n'avez-vous pas besoin d'asynchronie dans ce cas ?
Mais vous construisez NS sur des fonctions d'activation simples, vous n'avez donc pas été confronté au manque de concurrence.
Mais lorsque vous commencerez à construire des modèles globaux de NS, alors vous comprendrez la beauté de l'asynchronie.
mauvais exemple - pas nécessaire !
@Roffild a déjà écrit dans le fil de discussion"Dans le monde d'aujourd'hui, un programmeur doit connaître plusieurs langages afin de choisir le bon outil pour une tâche spécifique. "
c'est vrai !
Dans MQL il n'y a pas de choix de paquets pour MQL - seulement AlgLib - je veux considérer un exemple, trouvé sur le hubra, je prends et connecte C# ou Python à MQL - c'est tout, je fais ce que je veux faire, pas de portage de code vers MQL
De nos jours, les langages de programmation ne sont pas intéressants pour leurs fonctionnalités, mais pour leurs cadres de travail prêts à l'emploi ! - Si dans MQL il y aura de nouveaux paquets MQL, alors il y aura d'autres tâches et problèmes !
ZS : une fois de plus sur mes doigts, tu t'accroches à "l'idée de fx" qui est née des langages multiplateformes Python et Java, le sacrifice pour la portabilité et la flexibilité du langage était la perte de performance, maintenant ces langages ont été envahis par différentes façons d'augmenter la performance, mais dans les langages de type C les développeurs atteignent toujours la performance maximale et il n'y a pas besoin (dans la plupart des cas) de diviser la tâche en threads séparés (les tâches client - serveur ne comptent pas, là le problème est le taux d'échange de données et c'est une autre spécificité)
mauvais exemple - pas nécessaire !
@Roffild a déjà écrit dans le fil de discussion"Dans le monde d'aujourd'hui, un programmeur doit connaître plusieurs langages afin de choisir le bon outil pour une tâche spécifique. "
c'est vrai !
Dans MQL il n'y a pas de choix de paquets pour MQL - seulement AlgLib - je veux considérer un exemple, trouvé sur le hubra, je prends et connecte C# ou Python à MQL - c'est tout, je fais ce que je veux faire, pas de portage de code vers MQL
De nos jours, les langages de programmation ne sont pas intéressants pour leurs fonctionnalités, mais pour leurs cadres de travail prêts à l'emploi ! - Si dans MQL il y aura de nouveaux paquets MQL, alors il y aura d'autres tâches et problèmes !
ZS : encore une fois sur vos doigts, vous vous accrochez à "l'idée de fx" qui est née des langages multiplateformes Python et Java, le sacrifice pour la portabilité et la flexibilité du langage était la perte de performance, maintenant ces langages sont devenus entourés de diverses façons d'augmenter la performance, mais dans les langages de type C les développeurs atteignent toujours la performance maximale et il n'y a pas besoin (dans la plupart des cas) de diviser la tâche en threads séparés (les tâches client - serveur ne comptent pas, là le problème est la vitesse d'échange de données et c'est une autre spécificité)
Vous ignorez constamment les choses suivantes :
1. La distribution de programmes qui utilisent des connexions externes ne peut pas se faire via Market.
2. Les programmes qui utilisent des connexions externes exigent que l'utilisateur soit un "professeur" pour tout connecter correctement. Le mode d'emploi d'un tel programme est un véritable fouillis.
3. Les programmes utilisant des connexions externes ne conviennent qu'à un usage personnel, ce qui limite considérablement le sens de leur création.
4. Les programmes destinés à un usage personnel sont de moins bonne qualité que ceux destinés à la vente, car on peut tout faire pour soi... et on ne peut pas être le même expert dans plusieurs langues à la fois. Dans certaines langues, vous connaîtrez de la cinquième à la dixième langue, ce qui aura une incidence sur la qualité du produit.
5. De nombreuses tâches nécessitent l'utilisation de l'asynchronisme et du multithreading. Les programmes MQL n'ont pas encore atteint ces objectifs, mais cela ne signifie pas qu'ils ne doivent pas s'efforcer de les atteindre.
...
Ce qui permet d'atteindre l'asynchronie dans un seul flux.
Non, eh bien, l'asynchronie sans multithreading est vraiment une sorte de non-sens, il faut au moins un thread supplémentaire. Je pense que votre EventLoop peut être réalisé via des indicateurs chargeables. Communication entre indicateurs experts via des sockets, par exemple. Une tâche a été créée, l'indicateur a été connecté, la tâche a été envoyée, l'indicateur a rapporté l'exécution, nous demandons le statut de la tâche à l'Expert Advisor, supprimons l'indicateur. Par des béquilles, mais néanmoins par le multithreading.
Oui, cet article est très bien, pour une solution unique, pour y réfléchir, peut-être que vous pouvez tirer quelque chose d'autre de cette approche.
J'ai décidé de l'orientation de mon problème, merci à Andrey pour le conseil.
Le fait que vous ayez lu un article est une bonne chose.
Pas les threads, à savoir les appels non bloquants via les fonctions colback, contrôlés par EventLoop.
Cela permet de réaliser l'asynchronie dans un seul fil.
Comment avez-vous réussi à ne pas le trouver dans la documentation ?
Pourquoi ne le lisez-vous pas ?
Vous ignorez constamment les choses suivantes :
Vous et moi avons des tâches différentes, vous ne tenez pas compte du fait qu'il y a 2 grandes étapes dans l'écriture d'un logiciel : le développement du logiciel et la mise en œuvre elle-même.
Le développement de logiciels nécessite des solutions toutes prêtes - cela prend du temps. Si, au cours du développement, il s'avère que le logiciel ne remplira pas ses fonctions comme prévu, il sera mis à la poubelle. Et la mise en œuvre elle-même est un travail mécanique pour les capacités d'une plate-forme particulière.
5. De nombreuses tâches nécessitent l'asynchronie et le multithreading. Les programmes MQL n'ont pas encore atteint ces tâches, mais cela ne signifie pas qu'ils ne doivent pas s'y efforcer.
Ok, maintenant on y va avec toi :
Répondez à la question : pourquoi leterminal commercial en a-t-il besoin ?
Le fait que vous ayez lu un article est une bonne chose.
Comment avez-vous réussi à ne pas le trouver dans la documentation ?
Pourquoi ne le lisez-vous pas ?
Imaginez ne pas le trouver.
La recherche de callback et eventloop ne trouve rien de tel dans la documentation.
Si ça ne vous dérange pas, donnez moi un lien sans aucun sarcasme.
1. vous et moi avons des tâches différentes ; vous ne tenez pas compte du fait qu'il y a deux grandes étapes dans l'écriture d'un logiciel : le développement et la mise en œuvre.
Le développement de logiciels nécessite des solutions prêtes à l'emploi, ce qui prend du temps. Si, au cours du développement, il s'avère que le logiciel ne remplira pas ses fonctions comme prévu, il est perdu. Et la mise en œuvre elle-même est un travail mécanique pour les capacités d'une plate-forme particulière.
OK, maintenant on y va avec toi :
2. répondre à la question suivante : pourquoi leterminal de négociation en a-t-il besoin ?
1. Je ne fais que du développement. A peine 6 ans de développement continu, je ne comprends pas ce que c'est. )) Je pense que les solutions externes toutes faites, arrachées au contexte d'autres programmes ou abstraites de certains autres programmes, s'intègrent mal dans la structure d'un code hautement spécialisé et peuvent devenir très désordonnées. Dans ce cas, la main d'œuvre est plus importante que pour le développement de votre propre solution et la qualité finale du code est moindre. Sans parler du potentiel de développement. Ce sont les réalités du développement. Mais cela n'a rien à voir avec notre question. En fait, qu'est-ce que ça a à voir avec ça ?
2. Vous posez la mauvaise question. La question principale est "Pourquoi l'utilisateur final en a-t-il besoin ?". Parce que l'utilisateur est toujours à court de fonctionnalités. Il faut donc les ajouter pour qu'ils ne perdent pas leur intérêt. Si nous sommes à court de possibilités et que nous ne pouvons pas en ajouter de nouvelles en raison de limitations techniques, l'utilisateur abandonnera. Des opportunités sont nécessaires pour garder les utilisateurs sur le terminal et la distribution de logiciels est nécessaire à cet effet. Par conséquent, les programmes qui ne peuvent être distribués n'ont aucun sens pour la communauté, quels que soient les langages utilisés.
En fait, vous ne regardez que vos propres besoins et ne tenez pas compte des besoins des autres utilisateurs. Vous ne faites pas et ne voulez pas faire des affaires dans cette communauté, et vous ne diffusez que la motivation de faire de l'argent sur le marché. Et vous pouvez gagner de l'argent sur le marché sans aucun logiciel.
mauvais exemple - pas nécessaire !
@Roffild a déjà écrit dans le fil de discussion"Dans le monde d'aujourd'hui, un programmeur doit connaître plusieurs langages afin de choisir le bon outil pour une tâche particulière. "
c'est vrai !
Dans MQL il n'y a pas de choix de paquets pour MQL - seulement AlgLib - je veux considérer un exemple, trouvé sur le hubra, je prends et connecte C# ou Python à MQL - c'est tout, je fais ce que je veux faire, pas de portage de code vers MQL
De nos jours, les langages de programmation ne sont pas intéressants pour leurs fonctionnalités, mais pour leurs cadres de travail prêts à l'emploi ! - Si dans MQL il y aura de nouveaux paquets MQL, alors il y aura d'autres tâches et problèmes !
ZS : encore une fois sur vos doigts, vous vous accrochez à l'idée du "fix" qui est né des langages multiplateformes Python et Java, le sacrifice pour la portabilité et la flexibilité du langage était la perte de performance, maintenant ces langages sont devenus entourés de différentes façons d'augmenter la performance, mais dans les langages de type C les développeurs atteignent toujours la performance maximale et il n'y a pas besoin (dans la plupart des cas) de diviser la tâche en threads séparés (les tâches client - serveur ne sont pas incluses, là le problème est la vitesse d'échange de données et c'est une autre spécificité)
Igor, tu te contredis parfois.
La dernière fois, vous avez écrit que la vitesse de calcul du mql est comparable à celle du C++.
OK, c'est effectivement vrai et beaucoup de gens le savent.
Mais vous donnez ensuite un exemple de connexion de frameworks tiers pour porter les calculs, comme vous le dites, sur des langues en retard.
Et vous préconisez la connectivité des paquets de tiers. Vous sacrifiez donc la vitesse pour un cadre standard ?
Et donc, comme Peter l'a écrit, vous perdez complètement la portabilité de votre programme.
Ce n'est pas une bonne solution. Pour un usage personnel, oui, mais pas pour un usage de masse.
Imaginez ne pas le trouver.
La recherche de callback et eventloop ne trouve rien de tel dans la documentation.
Si vous le voulez bien, donnez-moi un lien sans sarcasme inutile.
Il ne faut pas faire de recherche, il faut tout lire. Je suis sûr qu'il y a beaucoup de surprises pour vous.
Il n'y aura pas de liens.
J'ai aidé plus d'une fois des gens ici qui avaient au moins essayé de faire quelque chose pour eux-mêmes.
Et qu'avez-vous fait ?
Vous restez là à surveiller votre bouche sur le forum ?
Et bien, je vous aide avec ça.