Séquence d'exécution de Init() et DeInit() - 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
Ça y est, les lamentations ont commencé...
Ce que vous demandez est exactement ce que les applications de bureau ordinaires n'ont pas.
Qu'est-ce qui n'est pas dans l'application ? Synchronisation ? )))
Si les développeurs ne faisaient pas toutes ces fonctionnalités qui sont déjà "prêtes à l'emploi", les auteurs de programmes MQL seraient constamment confrontés à tous les charmes du développement de bureau, qu'il s'agisse de sécurité ou de vitesse d'exécution.
1. Qu'est-ce qui n'est pas dans les applications ? Synchronisation ? )))
2) Vous faites des raisonnements non scientifiques sans faits. Dans MT4, les indicateurs fonctionnent avec des OnInit() et DeInit() successifs. Il y a un inconvénient : tous les indicateurs fonctionnent dans un seul fil. Ce problème peut être résolu en écrivant correctement l'indicateur, ce qui est également requis dans MT5. Bien que MT5 ne l'ait pas abandonné - de toute façon, les indicateurs d'un même graphique continuent de fonctionner dans un même fil.1. De quelle synchronisation parlez-vous ?
2. Dans MT4, dans le cadre de l'exécution du code de l'indicateur, init est d'abord exécuté et ensuite deinit, que faut-il de plus ! !! C'est la même chose dans MT5.
Plusieurs personnes m'ont déjà demandé de donner un exemple spécifique d'une tâche qui est problématique à réaliser dans le cadre du paradigme d'exécution des indicateurs dans MT5. Y aura-t-il un exemple ou non, un exemple clair, pas tiré par les cheveux ?
1. de quelle synchronisation parlez-vous ? !
A propos de l'inter-threading. Tant qu'un thread n'est pas terminé (celui qui a reçu l'ordre de se terminer), l'autre thread ne démarre pas. Ou, si tout se passe dans un seul fil, c'est encore plus simple : terminer tous les programmes associés à l'"ancien" TF et seulement ensuite lancer les programmes sur le "nouveau" TF.
2. Dans MT4, dans le cadre de l'exécution du code de l'indicateur, init est d'abord exécuté et ensuite deinit, de quoi d'autre avez-vous besoin ! Il en va de même dans MT5.
Bien. C'est exactement le cas dans MT4. Mais ce n'est pas le cas dans MT5. Et c'est là-dessus que porte le sujet.
Plusieurs personnes m'ont déjà demandé de donner un exemple spécifique d'une tâche qui est problématique à réaliser dans le cadre du paradigme d'exécution des indicateurs dans MT5. Y aura-t-il ou non un exemple, un exemple clair, qui ne soit pas tiré par les cheveux ?
C'est vrai, ils ne devraient pas. Vous exécutez donc Total Commander, par exemple. Pourquoi exiger de Microsoft que Windows s'occupe de la séquence "correcte" de chargement/ déchargement des copies de TC dans la RAM ? Est-ce une préoccupation de l'OS ?
L'OS se soucie que les CT n'interfèrent pas avec d'autres CT et ce qu'ils y font en RAM, échanger des fichiers ou autre, c'est leur affaire.
"Je pense que oui !" (c) Mimino, 1977.
Qu'est-ce que Total Commander a à voir là-dedans ? C'est juste un utilitaire de bas niveau dans le sens où il opère directement avec les ressources du système. Dans le cas de MQL, la tâche de la plate-forme MT est de libérer le programmeur d'application des soucis du système tels que la synchronisation - la plate-forme peut fournir cela plus efficacement et d'un seul coup pour tous. Les programmeurs MQL doivent penser à l'analyse des cotations et aux stratégies de trading. C'est l'objectif de MT.
Qu'est-ce que cela a à voir avec l'échange de fichiers et de données ? Considérons la logique du travail dans le contexte d'un programme MQL. Il tente simplement d'utiliser les événements OnInit/OnDeinit conformément à leur finalité - pour démarrer correctement à partir d'un certain état et se terminer correctement en sauvegardant cet état. S'ils ne sont pas adaptés à cette fin, alors, comme nous l'avons déjà noté, à quoi servent-ils ? À en juger par les arguments des défenseurs - pour que nous puissions danser à l'intérieur et découvrir quelles autres copies ont été exécutées avant et après, et à partir de quelle période et vers laquelle ils ont basculé ? Cela a exactement l'effet inverse de ce que MQ voulait obtenir, à savoir qu'une copie ne sait rien de l'autre.
Pour qu' une copie ne sache rien et n'ait pas à s'en occuper, tout en continuant à fonctionner sans effets secondaires, le noyau doit connaître toutes les copies - aussi bien celles qui sont arrêtées que celles qui démarrent - et leur fournir une gestion gracieuse des événements d 'init/deinit dans une métaphore de file d'attente standard. Le terminal suit toutes les copies de toute façon, et utilise la file d'attente des événements, mais pour une raison quelconque, l'init/deinit brise la logique des événements.
Pour qu'une copie ne sache rien et n'ait pas à le découvrir, tout en continuant à fonctionner sans effets secondaires, le noyau doit être conscient de toutes les copies - à la fois celles qui sont terminées et celles qui sont démarrées - et fournir une gestion gracieuse des événements d 'init/deinit pour elles dans la métaphore standard des files d'attente. Le terminal garde la trace de toutes les copies et utilise la file d'attente des événements, mais pour une raison quelconque, l'init/deinit rompt la logique des événements.
Quel est le problème de stocker la période dans une variable principale ?
Pourquoi serait-il nécessaire de transférer un tableau de données entre des exécutions successives de l'indicateur sur des TF différentes ?
Andrey, je n'aime pas les variables globales du terminal. Je les ai expérimentés (il y a longtemps) et j'ai été très déçu par leur vitesse et leurs difficultés de synchronisation. Pour éviter de manquer de soutien, je vais essayer d'écrire un exemple (un peu plus tard) qui démontre leur rapidité. Peut-être que quelque chose a changé et que je me trompe. Mais une autre chose que je n'aime pas à propos des variables globales est qu'elles ont leur propre vie et qu'elles sont absolument publiques. Chacun peut les vérifier en appuyant sur F3 et les supprimer. Lorsqu'il y en a plusieurs, c'est la moitié du problème, mais si tout le monde commence à les utiliser, j'ai personnellement l'impression qu'il y a du désordre sur mon bureau.
A propos du passage des tableaux. Oui, je suis d'accord, ce n'est pas nécessaire très souvent. Mais voici un exemple concret - mon indicateur. Son fonctionnement interne ne dépend pas du TF sélectionné, car lors de l'initialisation, il télécharge tous (presque tous) les TF et crée son propre tableau général (quelque chose comme un tableau logarithmique de cotations) et effectue quelques calculs plus volumineux de tableaux d'indices basés sur celui-ci. Lorsqu'on change de TF, il n'est pas du tout rationnel de faire une seule et même quantité de travail à chaque fois - il y aura des retards lors du changement de TF. J'ai également en tête des algorithmes de reconnaissance de formes, que je vais mettre en œuvre, de sorte que les calculs d'initialisation peuvent prendre jusqu'à plusieurs secondes, et je voudrais que cela ne se produise qu'une fois et que l'on oublie tout.
Pour qu' une copie ne sache rien et n'ait pas à le découvrir, tout en continuant à fonctionner sans effets secondaires, le noyau doit être conscient de toutes les copies - à la fois celles qui sont terminées et celles qui sont démarrées - et fournir une gestion gracieuse des événements d 'init/deinit pour elles dans la métaphore standard des files d'attente. Le terminal suit toutes les copies de toute façon, et utilise la file d'attente des événements, mais pour une raison quelconque, l'init/deinit brise la logique des événements.
Imaginons maintenant qu'il n'y ait pas une seule file d'attente d'événements, mais plutôt une file d'attente pour chaque période de caractères. Autant de périodes de personnages, autant de files d'attente.
Proposez maintenant l'ordre dans lequel les files d'attente sont traitées.
Imaginons maintenant qu'il n'y ait pas une seule file d'attente d'événements, mais plutôt une file d'attente pour chaque période de symbole. Autant de périodes de symboles que de files d'attente.
Proposez maintenant l'ordre dans lequel les files d'attente sont traitées.
1. à propos de l'inter-threading. Tant qu'un thread n'est pas terminé (celui qui a reçu l'ordre de se terminer), l'autre thread ne démarre pas. Ou, si tout cela se passe dans un seul fil, c'est encore plus simple : nous terminons l'exécution de tous les programmes liés à l'"ancienne" TF et seulement après, nous démarrons les programmes sur la "nouvelle" TF.
2. Bien. C'est exactement la même chose dans MT4. Mais ce n'est pas le cas dans MT5. C'est le sujet.
3. j'ai donné travaille avec des objets graphiques, une beauté est née : un indicateur existe toujours et n'a pas été nettoyé, tandis que le second dessine par-dessus ces objets. C'est ainsi que l'on expliquera à l'utilisateur : "En commutant la TF, vous observerez des perturbations à court terme". )))1) Il devrait être fait comme je l'ai écrit plus tôt : la base de données accumulée devrait être périodiquement sauvegardée dans un fichier ou autre stockage, pas de problème - ouvrir le fichier, écrire, fermer. Vous devez le faire à chaque fois que vous mettez à jour ces données ou périodiquement, pas ininit et deinit. (Vous sauvegardez périodiquement votre travail lorsque vous écrivez un programme, rédigez un article). Et il est impossible de s'assurer contre l'échec de l'écriture dans le fichier, parfois pour s'assurer dans des situations d'importance critique, ils font ce qui suit : ils écrivent les informations mises à jour dans un nouveau fichier, après une écriture réussie, ils suppriment l'ancien fichier, et changent le nom du nouveau fichier comme il était dans l'ancien.
2) Je l'ai déjà expliqué. Chaque indicateur doit fonctionner avec ses propres objets graphiques. Bien sûr, nous devons vérifier l'existence des objets et s'ils existent déjà, nous devons ajouter 1 au nom de l'objet.
3) Vous avez déjà écrit qu'elle est soluble.
Et ce ne sont pas du tout des problèmes. Il s'agit du fonctionnement normal des programmes - création d'objets uniques, sauvegarde périodique des informations accumulées, nettoyage après achèvement.
1. Ce sont vos souhaits. Mais vous avez dit que vous vouliez la façon dont les applications de bureau fonctionnent, donc la façon dont vous voulez les applications de bureau ne fonctionne pas.
Comment appelez-vous les applications de bureau ? On a l'impression que MT5 n'est pas une application de bureau.
2. N'inventez pas d'histoires. La séquence de oninit et ondeinit est la même dans MT4 et MT5. Il n'existe pas de programme commençant par deinit.
Je n'invente rien. C'est le sujet du fil de discussion actuel. Le fait est que MT5 peut exécuter Init pour l'indicateur qui n'a pas encore DeInit. Oui, c'est vrai. Vous n'avez pas lu le sujet ?
3) OK, analysons les exemples :
1) Faites comme je l'ai écrit plus tôt : la base de données accumulée devrait être sauvegardée périodiquement dans un fichier ou un autre stockage, pas de problème - ouvrir le fichier, écrire, fermer. Vous devez le faire à chaque fois que vous mettez à jour ces données ou périodiquement, pas ininit et deinit. (Vous sauvegardez périodiquement votre travail lorsque vous écrivez un programme, rédigez un article). Et il est impossible de s'assurer contre l'échec de l'écriture dans un fichier. Parfois, pour s'assurer dans des situations d'importance critique, on procède comme suit : on écrit les informations mises à jour dans un nouveau fichier, après une écriture réussie, on supprime l'ancien fichier et on modifie le nom du nouveau fichier comme il l'était dans l'ancien.
Essayez de mettre à jour le même fichier plusieurs fois par seconde et partagez vos impressions.
2) Je l'ai déjà expliqué. Chaque indicateur doit fonctionner avec ses propres objets graphiques. Bien sûr, nous devons vérifier l'existence des objets et s'ils existent déjà, nous devons ajouter 1 au nom de l'objet.
Qu'est-ce que cela a à voir avec le fait d'ajouter 1 au nom ? Il s'agit du fait qu'il y a des objets graphiques du même indicateur mais des copies différentes de celui-ci sur l'écran en même temps. Techniquement, il n'y a pas de conflit. Il y aura un conflit pour l'utilisateur qui verra le chagrin sur l'écran jusqu'à ce que l'ancienne copie soit supprimée.
3) Vous avez déjà écrit qu'elle est soluble.
Ce n'est pas du tout un problème. Il s'agit du fonctionnement normal du programme - création d'objets uniques, sauvegarde périodique des informations accumulées, nettoyage après achèvement.