Erreurs, bugs, questions - page 1016
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
Écoutez, pourquoi en avez-vous besoin ? Si ce n'est pas un secret.
MQL5 n'a pas de fonctions en ligne (dans le formulaire) et j'utilise des macros paramétriques à la place.
Oui, je les utilise aussi, mais pas pour faire des nids. ))))
Pour votre référence, mql5 traduit toutes les petites fonctions en substitution inline. En d'autres termes, nous pouvons supposer que le mot clé "inline" se trouve par défaut dans chaque fonction définie par l'utilisateur.
La décision de substituer une macro ou de compiler dans une fonction est prise en dernier ressort par le compilateur (tout comme le C++, d'ailleurs). Il est donc inutile d'essayer d'accélérer les choses de cette façon, toutes les fonctions simples sont inlined de toute façon.
// Et d'ailleurs, avec un contrôle de type ! :)
Pour référence, mql5 traduit toutes les petites fonctions en substitutions inline. En d'autres termes, vous pouvez supposer que le mot clé "inline" se trouve par défaut dans chaque fonction utilisateur.
https://www.mql5.com/ru/forum/1111/page1013#comment_520221
Là, B() dans 1.mqh est censé être en ligne - mais tous ensemble - ne compile pas normalement - seulement séparément. Le ServiceDesk, se référant à l'ambiguïté de l'appel, n'a pas approfondi l'essence du problème et a recommandé d'organiser le projet d'une manière différente. Comment pourrait-on procéder différemment ? Tout ne fonctionne que lorsque je supprime l'implémentation B() de .mqh vers .ex5. Et qu'est-ce que le formulaire en ligne alors ?
À propos, dans MQL4, cet exemple fonctionne - sans erreurs, bien que B() ne soit pas inline en fait, mais en forme - inline.
Et je ne l'ai pas fait pour la vitesse, je l'ai fait pour la commodité. En substance, ils peuvent être en ligne, mais pas en forme ( !).
Et que dire de la forme.
"Qui est une Studebaker ? C'est votre parent Studebaker ? Ton père est une Studebaker ?"
Des difficultés apparaissent si vous définissez inline dans .mqh et l'utilisez ensuite dans plusieurs .ex5.
Il n'y a aucune difficulté. Si vous ne faites pas d'erreurs de logique et si vous comprenez correctement le fonctionnement d'un compilateur.
Je vais essayer de trouver le lien maintenant
https://www.mql5.com/ru/forum/1111/page1013#comment_520221
La fonction B() est ici essentiellement en ligne.
Je n'ai pas réussi à me débarrasser d'erreurs telles que "appel ambigu à une fonction surchargée avec les mêmes paramètres" - elles ne se produisaient pas à moins de la placer dans un fichier .ex5 distinct.
Vous avez une récursion essentiellement méconnaissable au niveau du code source ici. Le compilateur vous a désapprouvé miséricordieusement, juste sur le fond. Vous essayez de vous connecter à l'inluder a libu, qui définit le même inluder que celui dans lequel vous compilez. Alors, que voulez-vous ? Si vous étiez un compilateur, que feriez-vous ?
C'est peut-être une nouvelle pour vous, mais une fonction en ligne écrite dans une DLL ne peut en aucun cas être utilisée comme une macro en dehors de cette DLL. // En cours d'exécution, le code source n'existe plus.
Je pense que la deuxième nouvelle pour vous : toutes les librairies dans mql(4, 5) sont liées dynamiquement. Il s'agit essentiellement de DLL.
En résumé, vous essayiez en fait de faire référence d'une lib à elle-même, en vous référant à elle-même, en vous référant à elle-même...... etc.
D'accord, ce serait bien pire si tout était compilé sans objection, et qu'au moment de l'exécution, la librairie essayait de se charger récursivement jusqu'à ce qu'elle soit à court de mémoire..... :))
?
C'est pourquoi il existe le mot clé inline en C/C++.
Ce n'est pas du tout la raison. Je suis sûr que l'exemple du lien ne compilera pas en C++.
// Si je ne comprends pas comment construire un code source organisé de manière récursive, le compilateur ne le comprendra pas non plus.
Au fait, cet exemple fonctionne dans MQL4 - sans erreurs, bien que B() ne soit pas inline, mais en forme - inline
Je ne sais pas. Bien que... puisqu'il n'y a pas de surcharge de fonction à cet endroit, peut-être que le compilateur n'essaie pas de faire allusion à une surcharge erronée à cet endroit - il ignore simplement stupidement les définitions répétées.
Il compile en MQL4 ( !) et en C/C++ si vous écrivez en ligne avant B().
Il n'y a pas du tout de récursion ici, en fait il y a
int A( int ) et #define B() A( 0 )
C'est très simple - si vous n'êtes pas trop paresseux - jetez un coup d'oeil sur votre tête fraîche - il suffit de séparer la déclaration et l'implémentation des fonctions :)
Là, B() dans 1.mqh est censé être en ligne - mais l'ensemble ne compile pas normalement - seulement séparément. ServiceDesk se référant à l'ambiguïté de l'appel n'a pas approfondi le cœur du problème et a recommandé d'organiser le projet d'une autre manière. Et comment faire autrement ?
Cela ne fonctionne que si vous supprimez l'implémentation B() de .mqh dans .ex5. Qu'est-ce que le formulaire en ligne alors ?
Vous venez de répondre à votre propre question :
L'inline est normale ici. Le problème n'est pas du tout l'inineité de B(), mais sa redéfinition.
C'est juste que C/C++ comprend (en utilisant le mot-clé inline) qu'il ne s'agit pas d'une redéfinition, et MQL5 ne le fait pas, bien qu'il puisse distinguer par le nom du module compilé et celui spécifié dans #import. Je ne sais pas comment MQL4 le comprend.
En bref, vous ne pouvez pas définir une implémentation d'une fonction en .mqh et l'utiliser sans problème dans n'importe quel .ex5.
Tout à fait exact - c'est juste que C/C++ comprend qu'il ne s'agit pas d'une redéfinition, ce qui n'est pas le cas de MQL5.
C/C++ sont capables de comprendre ceci SEULEMENT lors de la compilation d'une librairie statique, parce que l'information sur le nom de la source est stockée dans le fichier objet (juste pour reconnaître la recompilation).
Avec les bibliothèques liées dynamiquement, cela ne fonctionnera pas, et si c'est le cas, ce n'est pas à cause de la détection de la réimplémentation, mais à cause des "règles de priorité" pour la congruence du nom de la source courante et de la DLL. Certains langages ont de telles règles (Delphi en particulier, probablement certains compilateurs C/C++ aussi).
En bref, vous ne pouvez pas définir une implémentation de fonction dans .mqh et l'utiliser sans problème dans n'importe quel .ex5.
:)
Mais lorsque vous utilisez un .ex5 pour appeler des fonctions sur un autre .ex5, même si la fonction portant ce nom existe dans les deux, vous devez vous assurer que vous spécifiez l'espace de nom avec précision. Autrement dit, la fonction ::In() devrait, en théorie, résoudre le problème. Et si ce n'est pas le cas, c'est un bogue qui doit être corrigé.