Il est temps de convertir les bibliothèques en MQL5 - page 6
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
En fait, il n'y a rien de mal à avoir un accès direct aux données.
Nous devons distinguer les domaines où le principe "il vaut mieux en faire trop que pas assez" est réellement applicable et utile.
À mon avis, le principe "Safety Comes First" ne devrait s'appliquer qu'au marché et au cloud. L'acheteur paie pour un produit qui est naturellement sécurisé et donc fermé, et il n'y a aucun moyen de vérifier la sécurité du produit. Par conséquent, le marché doit donner à l'acheteur une garantie à 100% de la sécurité de tous les produits. Et dans le cas du cloud, tous les ordinateurs du cloud doivent être protégés à 100 % contre les logiciels malveillants.
Et dans tous les autres cas, ne concernant pas la distribution de produits logiciels sur le marché et leur achat par le biais de ce service, ainsi que l'utilisation du cloud, l'entière responsabilité de l'utilisation de la dll non éprouvée incombe à l'utilisateur.
Avec cette approche, vous pouvez éviter bon nombre des problèmes actuels de dégradation des performances et des fonctionnalités du langage MQL5 dus à la "sécurité d'abord".
Par conséquent, le marché est obligé de donner au client une garantie à 100% de la sécurité de tous les produits.
Comment l'envisagez-vous ? En tant que vendeur, vous louez une place de marché à MK et exigez que le propriétaire soit responsable à 100 % de la sécurité de votre produit. C'est absurde.
Le marché donne déjà une garantie de sécurité des produits, car il interdit l'utilisation de dlls externes par les produits. Et les programmes MQL5 eux-mêmes fonctionnent dans le bac à sable interne sécurisé du terminal.
Vous n'étiez pas au courant ?
Je suppose que vous allez devoir changer beaucoup de choses.
Et vous essayez juste.
Les DLL raisonnables sont écrites à l'origine pour être intégrées à d'autres systèmes et ont donc des interfaces externes simples sous forme de fonctions brutes. Leurs fichiers d'en-tête sont simples.
En fait, il n'y a rien de mal à accéder directement aux données. Après tout, MetaTrader lui-même est probablement écrit en C/C++, et rien. De plus, les éditeurs de liens autorisent généralement les insertions en assembleur, ce qui est également acceptable. N'oubliez pas que MetaTrader fonctionnant sous Windows utilise directement ou indirectement un grand nombre de dlls système, et il n'y a rien de mal à cela non plus.
Je ne pense pas qu'il faille priver l'utilisateur de son droit de choisir. J'aimerais vraiment avoir la possibilité de prendre, par exemple, ALGLIB-dll et son (ses) fichier(s) d'en-tête natif(s) et d'utiliser une bibliothèque fiable sans y toucher de mes "mains maléfiques", mais en indiquant simplement au compilateur MQL qu'il s'agit d'un fichier d'en-tête C++ et non MQL.
Prenez la bibliothèque et utilisez les fonctions exportées des en-têtes avec des modifications mineures (si nécessaire).
Penser que l'on peut prendre n'importe quel fichier *.H d'un langage C/C++ peu sûr et l'utiliser dans un autre langage (encore plus sûr) est une incompréhension totale des langues. On peut rêver, mais on ne peut pas exiger.
La bibliothèque ALGLIB est déjà en cours de portage vers MQL5 et sera disponible dans le code source.
La question peut se poser : que faire si cette bibliothèque est malveillante et dangereuse ? Mais j'ai décidé de l'utiliser moi-même.
Posez cette question quelques millions de fois pour connaître le nombre d'utilisateurs finaux de MetaTrader et évaluer la qualité de la réflexion et de la responsabilité de ces millions de répondants.
C'est pourquoi nous veillons à la sécurité originelle de l'environnement.
En d'autres termes, MQL doit être aussi sûr que vous le souhaitez, mais si j'ai osé utiliser quelque chose d'externe, c'est mon problème personnel.
Penser que l'on peut prendre n'importe quel fichier *.H d'un langage C/C++ peu sûr et l'utiliser dans un autre langage (encore plus sûr) est une incompréhension totale des langues. Il est possible de rêver, mais il est impossible d'exiger.
La bibliothèque ALGLIB a déjà été portée sur MQL5 et sera disponible dans le code source.
Peut-être ai-je exprimé mon opinion en vain (d'ailleurs je n'ai rien exigé). Et concernant le manque de compréhension des langues, vous avez tout à fait raison. Plus je lis et plus je comprends, moins je comprends. Je ne comprends pas pourquoi si vous réécrivez ALGLIB pour mql5, et que vous le compilez ensuite avec un compilateur externe(visualc) en DLL, alors la bibliothèque sera plus sûre qu'en cas de compilation directe du code source original de la bibliothèque en DLL en une seule fois ?
Bon, d'accord. Qu'il en soit ainsi.
Je ne comprends pas pourquoi si on réécrit ALGLIB en mql5 et qu'on compile ensuite avec un compilateur externe(visualc) en une DLL,
Nous avons effectué un travail considérable pour affiner le compilateur MQL5 afin de faciliter la conversion des bibliothèques existantes écrites dans d'autres langages.
Et le développement du langage MQL5 se poursuit. De nouvelles fonctionnalités devraient bientôt apparaître, notamment un puissant profileur de code.
Nous avons maintenant deux tâches à accomplir :
1) sélectionner les bibliothèques tierces utiles pour la conversion
2) de rassembler des volontaires pour mettre en œuvre des projets de conversion (nous le financerons).
Nous aimerions commencer par une liste de projets potentiels. Aidez-nous avec des liens et des descriptions courtes, s'il vous plaît.
Puisque ALGLIB est déjà en cours de portage, la principale question sur le sujet est apparemment"quelle autre bibliothèque Open Source les utilisateurs aimeraient-ils voir ?"
Puisque ALGLIB est déjà en cours de portage, la question principale du sujet est apparemment "quelles autres bibliothèques open-source les utilisateurs aimeraient-ils voir ?".
Oui, je l'ai précisé dans mon premier message :
Nous sommes maintenant confrontés à deux défis :
1) choisir des bibliothèques open-source utiles pour la conversion
Vous vous trompez un peu. La réécriture en MQL5 est conçue pour ne pas utiliser de DLL, mais pour inclure tous les paquets mathématiques nécessaires directement dans le code source de MQL5.
Désolé, vraiment confus avec la capacité promise de compiler du code C/C++ dans une dll directement à partir du métaéditeur.
Mais pour moi, ce n'est toujours pas clair, pourquoi le porter, quand il (la bibliothèque) est déjà prêt à être utilisé comme une DLL ? Il se trouve que j'ai acheté un livre dans un magasin et qu'avant de le lire, je l'ai d'abord transcrit dans un carnet.
J'ai encore dû me tromper. Je n'écrirai plus rien.