Programmation asynchrone et multithread dans MQL - page 21
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
Voici un exemple d'écriture de code asynchrone linéaire dans un seul thread à titre d'illustration.
CTask *task2 = obj2.CALLBACK_FUNC(DeleteOrdersLimits(Magic)); //Выполняется асинхронно в пуле потоковcela ne fonctionnera pas :
mais lors de l'utilisation d'applications multithreads, le contrôle de ces threads est un casse-tête pour le développeur, il n'a pas vérifié l'état de préparation du calcul - il a obtenu un bug, qui apparaîtra à un moment inconnu.
OK, j'avais envie d'écrire dans un sujet portant un si beau nom - j'ai écrit, donc j'ai écrit... se souvenait de Don Quichotte et de son éternelle lutte contre les moulins à vent ))))
Une bonne équipe de professionnels, je pense qu'il y a encore des choses à discuter
....
Pourquoi, hypothétiquement, aurais-je besoin de votre interface graphique, etc., si elle peut être écrite en Sharp ou en Python en deux temps trois mouvements ? L'utilisateur ne se soucie pas de savoir dans quel langage il est écrit, il a besoin de la fonctionnalité, pas des spécificités de la mise en œuvre. Un programmeur n'a pas besoin de tels produits, mais un utilisateur s'en moque complètement, il se soucie du prix, et il est évident que Sharp est moins cher et plus fonctionnel.
1) Où trouverez-vous les acheteurs de vos programmes Sharp ?
2) Comment allez-vous prouver la sécurité de vos programmes ?
3. En tant que programmeur expérimenté, vous suggérez de ne pas utiliser un langage d'application pour le développement de TC, car Je n'ai pas compris pourquoi pendant des années.
4. Si vous proposez de faire un programme hybride - utiliser l'interface graphique de Sharp, et écrire la logique en MCL, - essayez de lier les tables de Sharp à l'Expert Advisor. Cela fait six mois, et l'article montrant comment faire n'a toujours pas été publié. Je soupçonne qu'il y a là de très sérieux problèmes. Et l'interface graphique au niveau des boutons - vous pouvez le faire avec une bibliothèque interne.
En bref, votre suggestion de conserver la LSC revient à suggérer de faire je ne sais quoi et d'aller là-bas, je ne sais où, parce qu'il semble qu'on y mange bien.....
cela ne fonctionnera pas :
Il fonctionne en C et C++ dans l'une des bibliothèques ;))
En quoi mql est-il différent de C++ ?
Si les développeurs le voulaient, ils pourraient implémenter cette fonctionnalité dans mql de façon très réaliste.
Après tout, l'idée elle-même est intéressante, d'autant plus que ces technologies sont bien connues.
Et il est fort probable que le travail sur les agents soit mis en œuvre de manière similaire, dans un pool de threads.
1) Où allez-vous trouver des acheteurs pour vos programmes Sharp ?
2) Et comment allez-vous prouver la sécurité de ces programmes ?
3. Vous, en tant que programmeur expérimenté, proposez de refuser d'utiliser un langage d'application dans le développement de TC, car... Je n'ai pas compris pourquoi pendant des années.
4. Si vous proposez de faire un programme hybride - utiliser l'interface graphique de Sharp, et écrire la logique en MCL, - essayez de lier les tables de Sharp à l'Expert Advisor. Cela fait six mois, et l'article montrant comment faire n'a toujours pas été publié. Je soupçonne qu'il y a là de très sérieux problèmes. Et l'interface graphique au niveau des boutons, vous pouvez le faire avec la bibliothèque interne.
En bref, votre suggestion de quitter MKL revient à suggérer de faire ceci, je ne sais quoi, et d'aller là-bas, je ne sais où, parce qu'ils semblent bien se nourrir là-bas.....
1. Cherchez les clients sur le côté. Le Marché n'est pas le seul endroit où les trouver.
Le Marché n'est pas une entreprise. Pour les MK, cela fait partie des affaires).
2., 3. и 4. Pour moi, le MKL (ou tout autre langage de n'importe quel terminal) n'est rien d'autre que le langage d'interface entre le terminal et le TS. Le CT ne doit pas dépendre du terminal, et doit pouvoir se connecter à n'importe quel terminal via une interface appropriée.
J'ai ce concept depuis le début. Tout cela est tout à fait réalisable, je ne vois aucun problème. Voici, par exemple, ce que la MCL fait avec la DLL.
Il n'y a pas d'importation de bibliothèques dans le MKL. Dans la base de données, nous voyons l'historique de TF 1m et du culbuteur. Tout cela est rempli en temps réel au fur et à mesure de la progression de la pièce.1. Cherchez des acheteurs à l'extérieur. Le Marché n'est pas une entreprise.
Le Marché n'est pas une entreprise. Ici, pour les MK, cela fait partie du métier).
2., 3. и 4. Pour moi, le MKL (ou tout autre langage de n'importe quel terminal) n'est rien d'autre que le langage d'interface entre le terminal et le TS. Le CT ne doit pas dépendre du terminal, et doit pouvoir se connecter à n'importe quel terminal via une interface appropriée.
J'ai ce concept depuis le début. C'est tout à fait faisable, je ne vois pas de problème.
1 et 2 sont sans réponse. Chercher dans un endroit peu clair et ne pas savoir comment convaincre que le programme est sûr... Et un manuel de 10 pages pour le lancer, comment connecter un TC écrit dans un langage non appliqué à toutes sortes de plateformes ? ))
TC multi-plateforme - voulez-vous parier ? - Étudiez pour devenir un programmeur et vous verrez comment !
Tu sais, tu me fais rire à chaque fois. Sérieusement. Un programmeur-praticien qui appelle à ne pas utiliser un langage d'application pour résoudre des problèmes hautement spécialisés, mais à résoudre ces problèmes dans des langages UNIVERSELS, au nom de l'UNIVERSALITÉ ! L'aspect pratique et l'opportunité jaillissent simplement de chaque phrase.
....
Il n'y a pas d'importation de bibliothèques dans le MKL. Dans la base de données, nous voyons l'historique de TF 1m et du verre. Tout cela est rempli en temps réel au fur et à mesure de la progression de la pièce.Non. Vous ne faites que transférer des données de la plateforme une fois par minute. Vous montrez une interaction en direct et remplissez le tableau de données plus d'une fois par seconde. Et les données doivent être transférées dans deux directions. De MKL à sharp et retour.
Tu sais, tu me fais rire à chaque fois. Sérieusement. Un programmeur-praticien qui appelle à ne pas utiliser un langage d'application pour résoudre des problèmes hautement spécialisés, mais à résoudre ces problèmes par des méthodes UNIVERSELLES et pour le bien de l'UNIVERSALITÉ ! L'aspect pratique et l'opportunité jaillissent de chaque phrase.
Pour être honnête, je m'amuse aussi en lisant vos posts. Sur les affaires, en particulier.
Je n'appelle personne à quoi que ce soit et je ne vends rien. Si vous voulez utiliser des threads, utilisez C++/C# et aucun problème. Ou vous pouvez vous plaindre éternellement qu'il n'y a pas de fils de discussion dans MKL.
Non. Vous ne faites que transférer des données de la plateforme une fois par minute. Vous montrez une interaction en direct et remplissez le tableau de données plus d'une fois par seconde. Et les données doivent être transférées dans deux directions. De MKL à sharp et retour.
Une fois par minute. Expert en technologie.)) Vous avez un événement -OnTick, vous appelez la fonction DLL sur celui-ci et passez les données actuelles sur la bougie. C'est tout.)
OK, oublie ça.
...
Si vous voulez utiliser des threads, utilisez C++/C# et aucun problème.