La différence entre extern et input - page 5

 
Alexey Navoykov:

Imaginons que ces initialisations soient faites dans différents fichiers include. Le résultat final dépendra alors de l'ordre dans lequel ces fichiers sont inclus.

Eh bien - même des bugs si évidents avec ces externes

J'écris donc qu'ils n'ont aucun sens, ils ne servent qu'à assurer la compatibilité avec l'ancien code - remplacer extern par input et corriger les erreurs... objectif peu clair.... extern n'a aucun sens - vérifiez-le

 
Alexey Navoykov:

Malheureusement, l'implémentation des variables externes dans MQL5 n'a pas été finalisée, et c'est pourquoi je ne recommande pas de les utiliser - cela pourrait causer des problèmes. Je veux dire le manque de contrôle sur l'initialisation obligatoire et unique de ces variables.

Par exemple, vous pouvez l'écrire de telle manière :

et il n'y aura pas d'erreur. Imaginez que ces initialisations soient effectuées dans des plugins différents. Le résultat final dépendra alors de l'ordre dans lequel ces fichiers sont inclus.

Ou nous pouvons l'écrire comme ceci (fichier exécutable) :

ici nous n'avons pas initialisé la variable externe du tout, mais il n'y a pas d'erreur non plus.

Par conséquent, il n'y a aucun contrôle sur le fait que les mêmes variables soient définies ou non dans d'autres fichiers. Vous pouvez accidentellement changer son nom, mais le programme compilera comme si rien ne s'était passé, bien que dans d'autres fichiers nous ayons une variable avec un nom différent.

Dans l'ensemble, il ne va nulle part. C'est pourquoi il est préférable d'utiliser des fonctions plutôt que des variables externes. Elles sont garanties d'avoir une seule définition, ni plus ni moins.

Avec cette approche, vous ne devriez pas utiliser d'ordinateur du tout. Parce que si vous fermez les yeux et tapez sur le clavier, vous obtiendrez des bêtises.

Le véritable problème de l'externalisation survient lorsque vous essayez de créer une externalisation à partir d'une entrée. Je ne me souviens pas des détails, c'est arrivé il y a longtemps. En conséquence, j'ai refusé tout extern, déclaré une simple variable dans le fichier include et fixé sa valeur dans l'EA inite par un appel de fonction.

 
Igor Makanu:

voilà - même des bugs aussi évidents avec ces externes

c'est pour cela que j'écris qu'ils n'ont aucun sens, ils sont seulement pour la compatibilité avec les anciens codes - remplacer extern par input et corriger les erreurs... sinon c'est écrit dans l'aide... objectif peu clair.... L'externalisation n'a aucun sens - peu importe comment vous cherchez.

Il y a un sens. Dans MT5, dans les fichiers inclus, l'extern n'est pas saisi du tout.

 
Dmitry Fedoseev:

C'est logique. Dans MT5, l'extern dans les fichiers include n'est pas du tout une entrée.

Pourquoi ajouter des externs aux fichiers include ?

Je ne sais pas ce qui se passe dans le monde moderne de l'écriture de programmes, mais j'ai appris à écrire dans le style procédural, puis j'ai commencé à utiliser la POO. Le premier et le second style impliquent que chaque unité logique doit être pleinement fonctionnelle lorsqu'elle est transférée dans un autre programme, c'est-à-dire qu'une fonction est écrite - sa description (en-tête) contient tous les paramètres qu'elle utilise - elle n'a pas besoin d'iprouts - vous coupez et collez cette fonction dans un autre fichier, elle a "bougé" telle quelle - la même chose avec les classes.

Et les iprouts eux-mêmes ne devraient créer que l'interface utilisateur, ils devraient toujours être décrits dans le fichier principal.


Et l'utilisation extern dans le fichier include, imho manière d'obtenir difficile de tracer le bug,@Alexey Navoykov ci-dessus a montré comment il se produit, malheureusement plus de la moitié des noms de variables tous les programmeurs ont à une lettre le même nom, la différence maximale dans l'utilisation des majuscules / minuscules, comme un exemple MagicNumber ou Magic - si vous regardez KB, puis toutes les autres variables, donc dans votre méthode est une menace de "ombre" extern dans sa variable, heureusement peu de gens utilisent maintenant ecterps

 
Igor Makanu:

pourquoi ajouter les iprtu dans les fichiers include ?

Je ne sais pas ce qui se passe dans le monde moderne de l'écriture de programmes, mais j'ai appris à écrire dans le style procédural, puis j'ai commencé à utiliser la POO, à la fois dans le premier et dans le second style, il est implicite que chaque unité logique doit être pleinement fonctionnelle lorsqu'elle est transférée dans un autre programme, c'est-à-dire que vous avez écrit une fonction - dans sa description (dans le titre) ont tous les paramètres qu'il utilise - il n'a pas besoin d'iprouts - couper cette fonction et inséré dans un autre fichier, il "déplacé" tel quel - la même chose avec les classes.

Et les iprouts eux-mêmes ne devraient créer que l'interface utilisateur, ils devraient toujours être décrits dans le fichier principal.

Ce n'est pas le cas. Dans les fichiers include, ajoutez des externs. Ainsi, dans les fichiers d'inclusion, vous pouvez utiliser les entrées déclarées dans le fichier principal.

D'ailleurs, il est presque toujours nécessaire dès que vous commencez à utiliser des fichiers include.

 
Dmitry Fedoseev:

Pas comme ça. Ajouter des externs aux fichiers d'inclusion. Ainsi, dans le fichier include, vous pouvez utiliser les entrées déclarées dans le fichier principal.

C'est d'ailleurs ce dont vous avez besoin presque dès que vous commencez à utiliser les fichiers include.

donnez un exemple de la raison pour laquelle l'externalité devrait être utilisée

 
Igor Makanu:

donnez un exemple de la pertinence de l'utilisation de l'externalisation.

Il existe depuis un certain temps maintenant.

 
Dmitry Fedoseev:

Vous ne devriez pas utiliser d'ordinateur du tout si vous adoptez cette approche. Parce que si tu fermes les yeux et que tu tapes sur le clavier, tu obtiens de la merde.

Bien sûr, nous obtiendrons les déchets, mais ils seront difficilement compilables. La tâche du compilateur n'est pas de compiler des déchets. Et dans ce cas, elle ne le fait pas.
 
Dmitry Fedoseev:

C'est depuis un moment maintenant.

C'est de ça que je parle.

Votre exemple est la génération de bugs cachés, le nom de la variable x est souvent utilisé..... a écrit ci-dessus

Je pense que c'est censé ressembler à ça :

extern int x;

int z()
  {
   static int x;
   x=122;
   return x;
  }
 
Igor Makanu:

C'est de ça que je parle.

Votre exemple est la création de bugs cachés, le nom de la variable x est souvent utilisé..... a écrit ci-dessus

Je pense que c'est censé ressembler à ça :

Pas du tout. La variable x ne doit pas être disponible uniquement dans une fonction, mais dans toutes les fonctions. Et plus encore, elle doit être disponible dans le fichier principal ainsi que dans tous les fichiers connectés.