Erreurs, bugs, questions - page 2564
![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
Toutes les mêmes règles s'appliquent aux statiques (private, protected, public), elles ne nécessitent simplement pas la création d'un objet.
Pas en général : par exemple, une statik publique ne peut pas être restreinte dans une classe dérivée
hmmm... Comment expliquer l'absurdité de la situation... Je vous ai suggéré de lire les posts des admins (développeurs), je vous ai montré l'aide qu'ils ont écrite, que voulez-vous de moi avec vos photos ?
Je ne me demande pas pourquoi il en est ainsi, je lis le forum et l'aide, et je fais ce qui est recommandé par les développeurs. Si vous pensez que c'est nécessaire, écrivez à "committee on protection of C++ standards", à UN... Eh bien, au moins l'administrateur dans le PM, si faible, mais alors verrouiller les messages des développeurs et obtenir votre chemin !
ZSY : J'ai réussi à insérer le code source et non les images, pourquoi le vôtre ne l'a-t-il pas fait ?
2019.09.17 22:11:49.534 tst (EURUSD,H1) 1:print
2019.09.17 22:11:49.535 tst (EURUSD,H1) 2:print
2019.09.17 22:11:49.535 tst (EURUSD,H1) 3:print
2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 2
2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 3
2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 4
Le seul bogue dans le code est dans l'accès à la méthode privée. Ce bug est apparu récemment.
La fonction ChartOpen renvoie toujours 0 dans le service. Bien que le tableau lui-même s'ouvre.
Le seul bogue dans le code est dans l'accès à la méthode privée. Ce bug est apparu récemment.
Je pensais avoir oublié quelque chose, alors j'ai relu comment les statiques se comportent en C#https://metanit.com/sharp/tutorial/3.6.php.
Les membres statiques d'une classe sont communs à tous les objets de la classe, vous devez donc les désigner par leur nom de classe :
Notez que les méthodes statiques ne peuvent faire référence qu'à des membres statiques de la classe. On ne peut pas adresser des méthodes non statiques, des champs, des propriétés à l'intérieur d'une méthode statique.
En MQL, les statiques sont initialisées avant d'exécuter OnInit(), discutons maintenant de la visibilité globale des méthodes privées pour les statiques..... ce comportement des statiques en MQL - si vous utilisez les statiques, cela signifie que nous n'utilisons pas les fonctions de protection des données d'une classe, à mon avis.
Quelle est la taille de cet insecte ? - la façon dont les développeurs le feront, j'ai dit que le comportement dans les opérations de contexte est déterminé par le programmeur (l'opérateur de résolution de contexte est l'opérateur avec la plus haute priorité dans le langage ! ), et le compilateur aidera correctement - enfin, comme il se doit)))
Est-ce que ça marche comme ça ?
dans l'ensemble, il fait le travail
PS : mis à jour en 2145 - le code avec les statiques se comporte de la même manière, si cela reste comme ça pendant six mois, il s'avérera que c'est le comportement prévu des statiques ;)
UPD : rappelez-vous, comme l'argot pour tout cela est appelé - dirty tricks ! ))) - Recherchez de nombreux exemples sur le web, où ce comportement est accepté comme une norme de langage, et où il est lié à un compilateur spécifique du fabricant. En Python, eval() ne casse-t-il pas effectivement l'exécution linéaire du code ? - Eh bien, certains le font et d'autres non, car le comportement est imprévisible.
UPD : vérifier sur 2145 ma question d'il y a un moishttps://www.mql5.com/ru/forum/320733#comment_12989063
https://www.mql5.com/ru/forum/320733#comment_12958594
rien n'a changé, sur une vérification du type bool le compilateur n'a pas appris à écrire des avertissements - c'est très désagréable, je cherchais une erreur dans mon code, bien que je sois sûr que le compilateur MQL vérifie toujours la correspondance des types
A quel point est-ce un bug ? - Peu importe comment les développeurs le transforment, c'est comme ça que ça va être.
Il est évident que le bug sera corrigé.
Rien n'a changé, le compilateur n'a pas appris à écrire des avertissements sur bool lors de la vérification des types.
La conversion automatique des pointeurs et des types numériques en bool est très pratique.
rien n'a changé, sur bool lors de la vérification des types le compilateur n'a pas appris à écrire des avertissements - c'est très désagréable, je cherchais déjà une erreur dans mon code, bien que j'étais sûr que le compilateur MQL surveille toujours strictement la correspondance des types
Il n'y a pas de perte de données pendant cette coulée. Soit 0, soit pas 0.
Un autre cas est celui où double -> tout type d'entier (jusqu'à et y compris int32)
Avec ce moulage, il n'y a pas de perte de données. Soit 0, soit pas 0.
Une autre chose est que lors du casting double -> tout type d'entier (jusqu'à et y compris int32)
mais dans l'autre sens ?
Je cherchais un bug dans mon code
Au début, j'ai écrit un test, mais j'ai d'abord utilisé int, puis j'ai renoncé à utiliser bool, mais je n'ai pas corrigé tout le code, je ne me souviens pas, mais c'était comme ça :
Je suis en quelque sorte prêt pour un tel comportement maintenant, mais pourquoi est-ce que j'écris à ce sujet...bien, en vérifiant les conditions MQL dans if() - est-ce qu'il contrôle strictement les types ? toute utilisation d'opérations non booléennes émettra un avertissement ? - Et de la même manière que j'ai écrit en C# dans VS2017 - mon code d'exemple ne compile pas et MQL ne lance pas d'avertissement. A mon avis, pour ceux qui sont nouveaux dans la programmation en MQL, un tel comportement implique quelques surprises.
Il est évident que le bug sera corrigé.
Je ne vais pas discuter, mais mon opinion est que vous ne devriez pas compter sur le contrôle du compilateur lorsque vous quittez la classe via les statiques ainsi que l'utilisation de l'opérateur de résolution de contexte,
Par exemple, si vous écrivez une méthode/un champ statique ou si vous utilisez :: : - ne comptez pas sur le compilateur.
Je ne vais pas discuter
J'ai décidé de décrire le problème dont nous discutons. D'ailleurs, le comportement de MQL est devenu de plus en plus similaire à celui de C#, le code ne compile pas
J'ai implémenté la méthode Inc() - elle fonctionne avec les champs protégés.
si j'ai ajouté un modificateur statique - où le compilateur doit-il arrêter de vérifier - j'ai décidé que j'avais besoin d'un point d'entrée vers un objet hors de la portée ?