OOP, templates et macros dans mql5, subtilités et utilisations - 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
A propos de la passe multiple - je me suis précipité, j'ai naïvement pensé que le mcl l'autoriserait.
Ну вот я с этого и начинал разговор тут. Планировал тоже заменять все статики на глобалы (хоть это и жесть конечно). Но как показано выше, с шаблонами такое не прокатит. С макросами тоже. А я всё это широко применяю. Поэтому и сделал свою реализацию. Хотя она конечно не решает всех проблем. Динамические массивы по-прежнему нельзя инициализировать, константные типы тоже. Поэтому их однозначно придётся выносить на глобальный уровень
J'utilise également beaucoup les modèles et les macros, mais je ne considère les fonctions libres que comme des éléments architecturaux auxiliaires (et généralement indésirables). Lorsque toutes les implémentations sont emballées à l'intérieur d'objets et que les statiques ne sont déclarées qu'au niveau des classes, des bogues gênants apparaissent, sauf que parfois il est difficile de comprendre la logique de leur séquence correcte de déclarations, afin que le compilateur ne jure pas...
Il y a donc des variables ici. Et avec les fonctions, oui, c'est multi-passable, donc tout était correct. Le problème se pose précisément à cause de l'ordre d'initialisation des fonctions. En bref, en C++ il y a un ordre strict qui s'applique aux variables, fonctions et types. Et en MQL tout est différent.
Les passes multiples sont mauvaises dans tous les cas - vous pouvez rencontrer des récursions, des blocages, etc. Mais le côté positif est que cela peut être fait. Par conséquent, ne le faites qu'à bon escient, avec précaution (c'est-à-dire avec une déclaration préalable), et non pas comme maintenant avec le compilateur multi-pass - car si pour n'importe quelle fonction une déclaration préalable est faite, tôt ou tard ce râteau vous frappera le front.
Le multipassing est mauvais dans tous les cas - vous pouvez rencontrer des récursions, des blocages, etc. Mais il est possible de faire une déclaration préalable, ce qui est un avantage. Par conséquent, ne le faites qu'à bon escient, avec prudence, et non pas comme maintenant avec le compilateur multipass - car si pour une fonction quelconque une déclaration en avant est faite, tôt ou tard ce râteau vous frappera le front.
Je suis d'accord. Ce sujet a été abordé un peu plus tôt. C'est ce que beaucoup d'entre nous aiment dans ce langage : on ne s'embarrasse pas de l'ordre de déclaration des fonctions. Inutile de dire que j'en étais moi-même heureux il y a quelque temps). Mais son côté fastidieux m'irritait. Mais avec l'expérience vient la compréhension.
J'utilise également beaucoup les modèles et les macros, mais je ne considère les fonctions libres que comme des éléments architecturaux auxiliaires (et généralement indésirables). Lorsque toutes les implémentations sont emballées à l'intérieur d'objets et que les statiques ne sont déclarées qu'au niveau des classes, des bogues gênants apparaissent, sauf que parfois il est difficile de comprendre la logique de leur séquence correcte de déclarations, afin que le compilateur ne jure pas...
Je suis d'accord, si tout est clairement aligné dans la POO, alors non seulement les fonctions libres ne sont pas nécessaires, mais aussi les méthodes template.
Les méthodes modèles sont nécessaires partout où l'on ne veut pas écrire un tas de code répétitif, qu'il soit OOP ou non OOP. Les fonctions libres sont une autre affaire - il s'agit de styles de programmation différents.
Les méthodes de modèle sont nécessaires lorsque vous ne voulez pas écrire un tas de code répétitif, qu'il s'agisse de POO ou de non-POO.
Dans la POO, les interfaces ont été inventées dans ce but.
Les interfaces sont un peu différentes. Si je veux que le même code fasse le même travail avec des types différents selon la classe du paramètre (sans déclarer de classes supplémentaires), les interfaces ne m'aideront pas.
Les interfaces sont un peu différentes. Si je veux que le même code fasse le même travail avec des types différents selon la classe du paramètre (sans déclarer de classes supplémentaires), l'interface ne m'aidera pas.
Si les paramètres sont de types différents, alors il est logique de créer plusieurs méthodes surchargées avec les types correspondants. Vous devrez toujours les séparer d'une manière ou d'une autre dans la fonction. Il est donc préférable de les diviser en fonctions séparées, plutôt que de créer un désordre qui prend également un type impersonnel, c'est-à-dire que par erreur vous pouvez passer n'importe quoi dedans et obtenir une erreur de compilation dans la bibliothèque, ce qui n'est pas bon. Et peut-être même pas, ce qui est doublement mauvais).
En bref, dans la POO à part entière, les fonctions de template sont une béquille (à quelques exceptions près).
En bref, les fonctions template sont une béquille dans la POO à part entière.
Alors nous y voilà.
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégies de trading
Caractéristiques du langage mql5, conseils et astuces
Alexey Navoykov, 2019.01.25 10:11
Eh bien, c'est comme ça que j'ai commencé la conversation ici. J'avais l'intention de remplacer toutes les statiques par des globales aussi (bien que ce soit une chose cruelle, bien sûr). Mais comme montré ci-dessus, cela ne fonctionnera pas avec les modèles et les macros aussi. Et je les utilise tous largement. C'est pourquoi j'ai créé ma propre implémentation. Bien qu'elle ne résolve pas tous les problèmes. Les tableaux dynamiques ne peuvent toujours pas être initialisés, ni les types constants. C'est pourquoi ils devront définitivement être globalisés.