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
Expet :
Duck, tu as une bibliothèque. Bien sûr, il y aura différentes variables. Il s'agit de la connexion de mqh via include.
En C++, les externs sont juste décrits dans les bibliothèques include, sinon le compilateur ne vous laissera pas compiler le projet
externe :
l'incluseur sera inséré dans le corps du programme lorsque vous le compilerez. si vous voulez décrire l'incluseur à cet endroit, la même chose se produira
vous pouvez également décrire une classe ou une structure externe avec le modificateur ;)
En C++, les externs sont décrits dans les bibliothèques include, sinon le compilateur ne vous laissera pas compiler le projet.
La façon habituelle d'appeler une bibliothèque est d'utiliser "#include" comme nom du fichier
...
L'intérêt de ceci est que l'incluseur sera inséré dans le corps du programme lors de la compilation, si vous voulez y décrire une instance, la même chose se produira.
Le but est de permettre de traiter le fichier à lier indépendamment de l'ensemble du projet, de le compiler séparément et de vérifier ainsi les erreurs.
L'objectif est de pouvoir travailler sur un fichier de plug-in indépendamment de l'ensemble du projet, de le compiler séparément et de vérifier ainsi l'absence d'erreurs.
Je pense que nous attendons le moment où il n'y en aura plus.
l'extern a été conservé pour la compatibilité avec des milliers de codes écrits précédemment et l'aide a été écrite par un gars qui a copié certaines informations du wiki.
Je pense que nous cherchons du sens là où il n'y en a pas.
imho, extern a été retenu pour la compatibilité de milliers de codes écrits auparavant, et l'aide a été écrite par une personne qui a copié certaines des informations de wiki
Alors, quel est le verdict de ces messieurs) ? Si j'écris un programme .mq5 avec .mqh (#include), je peux sans risque écrire extern et ne pas avoir peur de conséquences inattendues (comme je le faisais dans mql4) ou utiliser input ?
Cela dépend des objectifs. Ils ont des objectifs différents.
Alors quel est le verdict messieurs) ? Si j'écris un programme .mq5 avec .mqh (#include), je peux sans risque écrire extern et ne pas avoir peur de conséquences inattendues (comme je le faisais dans mql4) ou dois-je toujours utiliser input ?
Utilisez les constructions de code MQL standard : toutes les entrées au début du code, puis toutes les inclusions. C'est ainsi que les exemples des développeurs sont écrits, et 99% du code dans la codobase sont écrits de cette façon, et vous n'aurez pas de surprises.
Encore une fois sur extern - ils peuvent être changés pendant l'exécution du programme, mais à mon avis c'est une mauvaise pratique, habituellement toutes les variables externes dans OnInit () sont copiées dans leurs variables et ensuite travailler avec eux (comme un exemple d'experts qui travaillent pour 4-character et 5-character - exemples de cette conception dans les tonnes de réseau)
Et la ligne de fond - n'utilisez pas extern, si vous modifiez un ancien code, remplacez-le par input et le compilateur vous aidera avec des avertissements s'il y avait un enregistrement dans extern - vous devez le corriger
Au fait, j'ai découvert que le compilateur ne se soucie pas du fait que je puisse redéclarer le contenu de l'enum comme une variable.
Au fait, j'ai découvert que le compilateur ne se soucie pas du fait que je puisse redéclarer le contenu de l'enum comme une variable.
que se passe-t-il si je déclare une variable enum?
conversion enum implicite tst1.mq5 24 17
vous pouvez également vérifier EnumToString()
Je pense que le type sans variables déclarées a simplement été rejeté de la compilation comme non utilisé.