Discussion de l'article "Exposer le code C# à MQL5 à l'aide d'exportations non gérées"
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
Un nouvel article Exposer le code C# à MQL5 à l'aide d'exportations non gérées a été publié :
Dans cet article, j'ai présenté différentes méthodes d'interaction entre le code MQL5 et le code C# géré. J'ai également fourni plusieurs exemples sur la façon de rassembler des structures MQL5 contre C# et d'appeler des fonctions DLL exportées dans des scripts MQL5. Je pense que les exemples fournis peuvent servir de base à de futures recherches sur l'écriture de DLL en code géré. Cet article ouvre également la porte à MetaTrader pour utiliser de nombreuses bibliothèques déjà implémentées en C#.
Étant donné que la plupart des lecteurs ne sont peut-être pas conscients de la différence entre le code géré et non géré, je vais le décrire en quelques phrases. Fondamentalement, MetaTrader utilise le langage MQL pour implémenter des règles de trading, des indicateurs, des conseillers experts et des scripts. Il peut cependant utiliser des bibliothèques déjà implémentées dans d'autres langages et les lier dynamiquement pendant l'exécution. Ces bibliothèques sont également appelées DLL ou Dynamic Link Libraries.
Les bibliothèques sont en fait des fichiers binaires contenant du code source compilé pouvant être invoqué par un certain nombre de programmes externes pour effectuer des opérations spécifiques. Par exemple, la bibliothèque de réseau neuronal peut exporter des fonctions pour la formation et les tests de réseaux de neurones, la bibliothèque de dérivée peut exporter des calculs de différentes dérivées, la bibliothèque de matrices peut exporter des opérations sur des matrices. Les DLL pour MetaTrader sont devenues de plus en plus populaires car elles permettaient de masquer des parties de l’implémentation d'indicateurs ou d' Expert Advisors L'une des principales raisons d'utiliser les bibliothèques est de réutiliser le code existant sans avoir besoin de l'implémenter encore et encore.
Avant que .NET n'existe, toutes les DLL compilées par Visual Basic, Delphi, VC++, que ce soitCOM, Win32 ou C++ simple, pouvaient être directement exécutées par le système d'exploitation. Nous appelons ce code non géré ou code natif. Ensuite, .NET a vu le jour et a fourni un environnement très différent.
Le code est contrôlé (ou géré) par .NET Common Language Runtime -CLR. Les compilateurs CLR sont tenus de produire à partir du code source, qui peut être écrit dans plusieurs langues différentes, des métadonnées et un langage intermédiaire commun -CIL.
CIL est un langage de niveau supérieur indépendant de la machine et les métadonnées décrivent entièrement les types d'objets décrits par CIL conformément à la spécification de type commun -CTS Étant donné que CLR connait tout sur les types, il peut nous fournir un environnement d'exécution géré. La gestion peut être considérée comme un ramasse-miettes - gestion automatique de la mémoire et suppression d'objets et assurer la sécurité - protection contre les erreurs courantes dans les langues natives qui pourraient provoquer l'exécution de code étranger avec des privilèges d'administrateur ou simplement une surcharge de mémoire.
Il faut mentionner que le code CIL n'est jamais exécuté directement - il est toujours traduit en code machine natif par JIT (Just-In-Time) compilation ou par pré -compilation du CIL en assembleur. Pour une personne qui lit ceci pour la première fois, la notion de code en mode géré peut être déroutante, c'est pourquoi je colle le flux général dans CLR ci-dessous :
Figure 1. Common Language Runtime
Auteur : investeo