Programmation asynchrone et multithread dans MQL - page 5
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
Le problème principal n'est pas dans le "...encore à apprendre".
Le principal problème est que plus toutes ces mises en garde sont nombreuses, plus le risque d'obtenir des erreurs délicates, qui ne sont pas faciles à calculer, est grand.
Et tout cela constitue un casse-tête supplémentaire pour les développeurs.
De plus, il est bon d'évaluer si beaucoup de gens ont vraiment besoin de ce multithreading ?
Le problème principal n'est pas "...encore à apprendre".
Le principal problème est que plus tous ces artifices sont nombreux, plus le risque d'obtenir des erreurs délicates, très difficiles à calculer, est grand.
Tout cela constitue un casse-tête supplémentaire pour les développeurs.
De plus, il est bon d'évaluer si beaucoup de gens ont vraiment besoin de ce multithreading ?
Eh bien, une truie et un cheval, alors, et c'est parti... vers l'aube du matin...
Dommage que mql ne dispose pas d'une telle fonctionnalité,
Ladirection suggérera de développer une fonction mql standard pour la programmation asynchrone,
car il y a des problèmes de fils et surtout de sécurité.
Pour le mode asynchrone, je pense qu'il n'y a pas d'obstacles à la sécurité.
J'étais chez ma belle-mère hier, ils sont en train de rénover les murs, faites-vous de même ? - Ouvrez les fenêtres, aérez les pièces !
Rien ne s'y oppose ! La tâche consistait à utiliser une pure WinAPI. Sans aucune dll artisanale !
Le sujet a été créé pour discuter des problèmes de programmation mql multithreaded. Vous avez une sorte d'esprit négatif aujourd'hui, quel genre d'inondation dans le sujet, que j'ai créé moi-même ?
Pourquoi WinAPI ? Laissez-moi vous dire un secret, CLR est aussi "pur Windows", le support natif des bibliothèques .NET avec l'importation de fonctions "intelligentes" a été ajouté il y a un an, vous connaissez WinAPI, mais vous ne pouvez pas créer un fil dans .NET ? )))))
Veuillez vous abstenir de tels commentaires.
Eh bien, une charrue et un cheval, et en avant... vers l'aube du matin...
Dimitri, as-tu essayé de cultiver et de récolter avec une charrue et un cheval ?
Il y a tout autant de subtilités et de possibilités d'erreurs. Mais ça coûte beaucoup plus cher si la récolte meurt et que vous avez faim...
Il y a des problèmes partout, et il faut mesurer le bénéfice par rapport à l'effort à fournir. En particulier, avec ce multithreading. Je ne vois pas où il est si directement nécessaire.
Je n'ai pas simplement suggéré à l'auteur d'écrire son premier programme en pure WinAPIhttps://www.mql5.com/ru/forum/318593/page2#comment_12565043.
il y a beaucoup d'informations sur ce sujet sur le net - d'abord écrire en utilisant des fichiers d'en-tête prêts à l'emploi (windows.h et ainsi de suite), ensuite supprimer ces fichiers d'en-tête et se rapprocher de la WinAPI pure tant appréciée = un gros morceau de code qui peut enregistrer un processus et une fenêtre, qui peut recevoir des événements et les gérer.... et ce sera juste une fenêtre triviale qui ne peut rien faire d'utile, mais qui comprendra la quantité de travail que vous devez faire en utilisant WinAPI
J'ai essayé il y a environ 15 ans (je ne me souviens pas exactement, je me rappelle qu'il s'agissait d'une connexion par ligne commutée) et de cette façon, tout "je suis ingénieur en logiciel chez ma mère" devrait passer. de se débarrasser des questions et du désir de donner des conseils aux programmeurs de systèmes - développeurs de compilateurs
"ayant suivi cette voie", on comprendra tout de suite le travail colossal de centaines de programmeurs de systèmes qui écrivent des compilateurs et des bibliothèques pour eux, on comprendra pourquoi la vitesse a été dotée d'une fonctionnalité pratique pour l'utilisateur, de sorte que tout programmeur d'application peut lire l'aide et "en 2 clics" obtenir le résultat souhaité
SZZ : en général, le manque d'expérience, de connaissances et de compétences a provoqué une autre distorsion cognitive ))))
Le problème principal n'est pas "...encore à apprendre".
Le principal problème est que plus tous ces artifices sont nombreux, plus le risque d'obtenir des erreurs délicates, très difficiles à calculer, est grand.
Tout cela constitue un casse-tête supplémentaire pour les développeurs.
De plus, il est bon d'évaluer combien de personnes ont réellement besoin de ce multithreading ?
Dimitri, avez-vous essayé de faire pousser et de récolter des cultures avec une charrue et un cheval ?
Il y a tout autant de subtilités et de possibilités d'erreurs. Mais ça coûte beaucoup plus cher si la récolte meurt et que vous avez faim...
Il y a des problèmes partout, et il faut équilibrer le bénéfice obtenu et l'effort dépensé. En particulier, avec ce multithreading, je ne vois pas où il est si directement nécessaire.
C'est quoi une charrue et un cheval ? La pelle habituelle.
Si nous voulons être sérieux et matures, la première tâche qu'il serait utile de déplacer vers un fil séparé pour le travail asynchrone est WebRequest, mais en général, c'est bon, vous pouvez vivre avec ça aussi.
La deuxième tâche est l'entraînement des réseaux neuronaux, l'auto-optimisation intégrée à Expert Advisor. S'il était possible de créer facilement des fils de discussion à partir d'Expert Advisor, ce sujet prendrait un grand essor.
Si nous sommes sérieux et matures, la première tâche qu'il serait utile de mettre dans un thread séparé pour le travail asynchrone est WebRequest, mais en général, cela fera l'affaire, et nous pouvons vivre avec.
La deuxième tâche est l'entraînement des réseaux neuronaux, l'auto-optimisation intégrée à Expert Advisor. S'il était possible de créer facilement des fils de discussion à partir d'un conseiller expert, ce sujet prendrait un nouvel essor.
Dans MQL uniquement, les deux tâches sont résolues en lançant automatiquement le conseiller expert.
Je n'ai pas simplement suggéré à l'auteur d'écrire son premier programme en pure WinAPIhttps://www.mql5.com/ru/forum/318593/page2#comment_12565043.
il y a beaucoup d'informations sur ce sujet sur le net - d'abord écrire en utilisant des fichiers d'en-tête prêts à l'emploi (windows.h et ainsi de suite), puis supprimer ces fichiers d'en-tête et se rapprocher de la pure WinAPI tant appréciée = un gros morceau de code qui peut enregistrer un processus et une fenêtre, qui peut recevoir des événements et les gérer.... et ce sera juste une fenêtre triviale qui ne peut rien faire d'utile, mais qui comprendra la quantité de travail que vous devez faire en utilisant WinAPI
J'ai essayé il y a environ 15 ans (je ne me souviens pas exactement, je me rappelle qu'il s'agissait d'une connexion par ligne commutée) et de cette façon, tout "je suis ingénieur en logiciel chez ma mère" devrait passer. de se débarrasser des questions et du désir de donner des conseils aux programmeurs de systèmes - développeurs de compilateurs
"ayant suivi cette voie", on comprendra tout de suite le travail colossal de centaines de programmeurs de systèmes qui écrivent des compilateurs et des bibliothèques pour eux, on comprendra pourquoi la vitesse a été dotée d'une fonctionnalité pratique pour l'utilisateur, de sorte que n'importe quel programmeur d'application peut lire l'aide et "en 2 clics" obtenir le résultat souhaité
ZS : en général, le manque d'expérience, de connaissances et de compétences a provoqué une autre distorsion cognitive ))))
Igor, tout le monde comme toi n'a pas un diplôme en programmation. Où vos professeurs vous ont-ils enseigné ? C'est pourquoi les qualifications sont hors de question.
C'est pour cette raison que l'idée d'une WinAPI pure est floue, je supposais que ce serait plus simple que ce que vous avez décrit.
J'étais totalement étranger à la programmation, et ce n'est que grâce à mql que j'ai commencé à apprendre le C/C++ sans professeurs ni conseils !
Mais, comme vous pouvez le voir, j'ai atteint les besoins asynchrones par moi-même. Oui, je ne sais peut-être pas quelque chose, mais j'apprends tout ce dont j'ai besoin.
Oui, je ne connais pas la technologie .NET et je ne veux pas la connaître, j'en ai marre de C#, chacun a sa propre portabilité des langages.
Où m'avez-vous vu donner des conseils aux développeurs ? Une suggestion a été faite pour ajouter à mql un ensemble de fonctions standard pour travailler avec du code asynchrone.
C'est une proposition sensée, je ne sais pas pourquoi vous avez réagi si négativement à cette proposition... Ou peut-être que votre façon de parler est toujours comme ça ?
Si vous n'avez pas besoin de cette fonctionnalité, d'autres utilisateurs en ont besoin. C'est comme avec la POO, tout le monde ne l'utilise pas, mais elle est là. L'asynchronie semble être présente dans de nombreux langages maintenant, mais pas dans mql.
En quoi mql est-il pire que d'autres langages, du fait qu'il est privé de méthodes asynchrones ? La question des threads est close, tandis que l'asynchronie est implémentée d'emblée.
Igor, tout le monde comme toi n'a pas un diplôme en programmation. Où vos professeurs vous ont-ils enseigné ? C'est pourquoi la qualification est hors de question.
C'est pour cette raison que l'idée d'une WinAPI pure est floue, je supposais que ce serait plus simple que ce que vous avez décrit.
Je n'étais pas du tout familiarisé avec la programmation auparavant, et ce n'est que grâce à mql que j'ai commencé à apprendre le C/C++ sans tuteurs ni conseils !
Mais, comme vous pouvez le voir, j'ai atteint les besoins asynchrones par moi-même. Oui, je ne sais peut-être pas quelque chose, mais j'apprends tout ce dont j'ai besoin.
Oui, je ne suis pas familier avec la technologie .NET, et je ne veux pas l'être, j'en ai marre de C#, chacun a sa propre portabilité des langages.
Où m'avez-vous vu donner des conseils aux développeurs ? Une proposition a été faite pour ajouter à mql un ensemble de fonctions standard pour travailler avec du code asynchrone.
C'est une proposition sensée, je ne sais pas pourquoi vous avez réagi si négativement à cette proposition... Ou peut-être que votre façon de parler est toujours comme ça ?
Si vous n'avez pas besoin de cette fonctionnalité, d'autres utilisateurs en ont besoin. Je pense que tous les langages ont maintenant l'asynchronie, mais mql ne l'a pas.
En quoi mql est-il pire que les autres langages, du fait qu'il est privé de méthodes asynchrones ? La question des threads est close, mais l'asynchronie est réalisable.
Dans MQL5 il y a l'asynchronie, par exemple,OrderSendAsync.
Quant à l'interaction avec le réseau ou le système de fichiers - utilisez WinAPI, j'ai écrit la solution ci-dessus. Je pense que tout est là pour ça. Vous pouvez lire comment utiliser ces méthodes sur le site de Microsoft. Qu'est-ce qui n'a pas été divulgué ?)