Erreurs, bugs, questions - page 2639
![MQL5 - Langage des stratégies de trading intégré au terminal client MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Vous ne comprenez toujours pas de quoi il s'agit, vous ne lisez probablement pas mes messages avec attention. Mon appel s'adresse aux développeurs, pas à vous. Je n'ai pas besoin de tes conseils minables.
Calmez-vous et ne vous inquiétez pas tant.
Une fois de plus, je suis convaincu que les personnes ayant un faible développement cérébral ont généralement peu de compréhension de la civilité.
Vous ne comprenez même pas ce que vous disent des personnes plus compétentes, et vous êtes aussi grossier qu'un enfant de maternelle qui n'a même pas appris à écrire correctement.
Cependant, c'est le travail sur les projets qui vous permet d'évaluer les capacités de la langue et de découvrir ses défauts et ses bogues...
Auparavant, lors du travail sur les projets MQL, les informations sur les défauts (bugs) étaient fournies dans l'ordre de leur détection.
Nous avons maintenant décidé d'essayer une nouvelle approche - travailler jusqu'à un défaut bloquant et ensuite fournir des informations sur tous les défauts détectés.
Vous créez plusieurs fois un objet enveloppé complexe avec le type interne "C", mais il s'avère être un type de données tout à fait différent, peut-être "B", "int", ce que vous voulez...
Il m'a fallu beaucoup de temps et d'efforts pour trouver et comprendre que le problème ne se situe pas dans le code mais dans le compilateur MQL. (C++ en ligne: https://onlinegdb.com/H1R1fR5ML)
Vraisemblablement, le problème se situe dans le travail du cache de la classe de modèle "main_wrapper" lors de la génération du code à la compilation lorsque la classe interne "internal_wrapper" de la classe de modèle "A" est passée en paramètre pour différents types de données (int, B*, B, C).
Le premier type de données est créé par la classe de modèle "main_wrapper<A<TEMPLATE_TYPE>::internal_wrapper>, ce type de données sera utilisé ultérieurement dans tous les objets du modèle.
Un autre bogue concernant la génération du code de la classe du modèle sera présenté ci-dessous.
Un autre bogue MT5 (build 2316) avec la génération de code de classe de modèle lors de l'utilisation de classe interne.
C++ en ligne: https://onlinegdb.com/HJkKXAqMU
Un autre défaut deMT5(build 2316) lié à laclasse interne est l'absence de possibilité de référencer explicitement l'espace de nom global.
C++ en ligne: https://onlinegdb.com/H14NF05G8
Un bogue très désagréable qui bloque la poursuite du développement.
Vous créez plusieurs fois un objet enveloppé complexe avec le type interne "C", mais il s'avère être un type de données tout à fait différent, peut-être "B", "int", ce que vous voulez...
Il m'a fallu beaucoup de temps et d'efforts pour trouver et comprendre que le problème ne se situe pas dans le code mais dans le compilateur MQL. (C++ en ligne: https://onlinegdb.com/H1R1fR5ML)
Vraisemblablement, le problème se situe dans le travail du cache de la classe de modèle "main_wrapper" lors de la génération du code à la compilation lorsque la classe interne "internal_wrapper" de la classe de modèle "A" est passée en paramètre pour différents types de données (int, B*, B, C).
Le premier type de données est créé par la classe de modèle "main_wrapper<A<TEMPLATE_TYPE>::internal_wrapper>, ce type de données sera utilisé ultérieurement dans tous les objets du modèle.
Un autre bogue concernant la génération du code de la classe du modèle sera présenté ci-dessous.
Est-ce la bonne façon de procéder ?
Merci, en effet l'introduction d'un paramètre de modèle fictif, dans le cas de l'exemple, permet de contourner le problème.
Cependant, en ce qui concerne le projet global, les choses sont un peu plus compliquées : laclasse interne a été utilisée comme une alternative à la fonctionnalité manquante typedef typename afin de simplifier à la fois le processus de développement et l'application de la classe conteneur finale.
Cela vaut peut-être la peine d'attendre une correction de la part des développeurs.
En dernier recours, il faudra faire glisser toutes les dépendances vers l'extérieur, en espérant ne plus réussir la compilation avec un comportement indéfini au moment de l'exécution.
Pour résumer la fonctionnalité de la classe interne,
nous pouvons clairement dire qu'il manque la fonctionnalité de déclaration typedef, du moins sa forme primitive, pour l'utiliser correctement...
Ainsi, au lieu d'un code C++ assez compact et clair :
Nous devons construire une barrière avec #define et l'héritage par la classe interne :
Problèmes lors de l'utilisation d'une classe interne comme déclaration typedef :Et il y a beaucoup plus de problèmes ici qu'il n'y paraît à première vue.
Des problèmes surviennent lors de l'utilisation de #define comme déclaration typedef :
Les développeurs ont ajouté "operator= delete" à cet effet.
Cependant, il ne semble pas logique de rompre le lien suppression/par défaut, car tout doit être réécrit manuellement.
Peut-être que je fais quelque chose de mal ?
Il y a une erreur dans la documentation sur le site web:
Calculs basés sur les séries chronologiques de la période actuelle
Des parenthèses formées au lieu de parenthèses carrées.