Mon approche. Le noyau est le moteur. - page 166
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
Peter, où est la preuve ?
Je peux vous fournir la preuve du faible coût de l'échange de données entre programmes. Même en passant une chaîne de milliers de caractères. J'ai fait une expérience. Je vais trouver et télécharger deux EAs de test. La communication via les ressources ne charge pas le processeur, mais uniquement le redécoupage.
Le moteur accumulera un large éventail de fonctionnalités, et seulement une petite partie - l'interface graphique de l'utilisateur. Autrement dit, le moteur comprendra un code qui ne sera que partiellement requis par une application distincte, et le reste du code pourra être utilisé par d'autres applications sur d'autres graphiques. De cette manière, le moteur devient une fonctionnalité auxiliaire utilisée par différents EA en même temps, et doit donc être un programme distinct fonctionnant dans son propre thread.
Ici. Mettez-le sur le premier graphique.
Et celui-ci est sur la deuxième.
Je peux apporter la preuve du faible coût de l'échange de données entre programmes. Même lors du transfert d'une chaîne de milliers de caractères. J'ai fait une expérience. Je vais trouver et télécharger deux EAs de test. La communication par le biais de ressources ne charge pas le processeur, mais uniquement le redécoupage.
Le moteur accumulera un large éventail de fonctionnalités, et seulement une petite partie - l'interface graphique de l'utilisateur. Autrement dit, le moteur comprendra un code qui ne sera que partiellement requis par une application distincte, et le reste du code pourra être utilisé par d'autres applications sur d'autres graphiques. De cette façon, le moteur devient un centre fonctionnel auxiliaire utilisé par différentes EA en même temps, et doit donc faire l'objet d'un programme distinct.
Mais si votre moteur sert plusieurs applications, il ralentira l'ensemble du processus, car il servira différents programmes de manière séquentielle, alors que les instances de votre classe de moteur dans chaque application fonctionneront en parallèle.
Les programmes accèdent au moteur de manière asynchrone et selon les besoins. L'un demandera de construire un graphique basé sur le tableau qui lui est passé, l'autre de calculer une valeur en utilisant une formule, le troisième quelque chose d'autre... Tout ceci ne sera pas un processus unique et continu, mais se produira de temps en temps.
Dans ce cas, le moteur portera l'interface graphique d'une des applications, et l'utilisateur passera à l'interface graphique d'une autre application.
Si vous mettez le moteur dans une application, il y a beaucoup de choses inutiles dans l'application. Vous devez donc adapter le moteur aux besoins spécifiques de chaque EA. L'utilisateur ne pourra pas y faire face. C'est long et compliqué. Et cela va interférer avec le développement de l'universalité du moteur.
Juste un tas de mots sans aucun sens.
Croyez-moi sur parole. Je sais ce que je fais.
Croyez-moi sur parole. Je sais ce que je fais.