Sujet intéressant pour beaucoup : les nouveautés de MetaTrader 4 et MQL4 - de grands changements en perspective - page 8
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
J'ai cherché et cherché. Je n'en ai pas trouvé...
Je ne l'ai pas dit comme ça.
Le débogueur n'a pas encore été pensé, c'est-à-dire qu'on ne sait pas s'il sera là, mais comme il n'a pas été pensé, cela signifie qu'il ne sera pas là "encore".
http://forum.mql4.com/ru/56881/page4#820225
Alors que vous êtes en train de régler les détails techniques de la mise à niveau, un détail important vous échappe : MetaTrader 4 aura Marketplace. Compte tenu de la prévalence du 4, vous pouvez estimer combien un développeur de robot/indicateur peut gagner sur le marché unifié de 7 millions de traders. MQL5 Les résultats du marché peuvent être utilisés comme base pour faire des hypothèses et pour avoir une meilleure idée du type de logiciel le plus populaire parmi les traders.
Vous n'êtes pas encore inscrit en tant que développeur ?
C-4:
Вот тут подумалось что при объединении двух языков абсолютно необходимы условные директивы компиляции типа #ifdef - это бы существенно упростило бы унификацию кодов между двумя платформами, и плотформозависимый API определялся на этапе компиляции.
Oui, ce serait bien.
Jusqu'à présent, j'ai utilisé comme alternative tordue une construction du type
#define _DEBUG_OR_RELEASE_(DEBUG, RELEASE) DEBUG
Mais il serait considérablement plus flexible avec #ifdef
Pendant que nous réglons les détails techniques de la mise à niveau, nous avons perdu un détail important : MetaTrader 4 disposera de la place de marché. Compte tenu de la prévalence de 4, vous pouvez estimer combien un développeur de robot/indicateur peut gagner sur le marché uni de 7 millions de traders. MQL5 Les résultats du marché peuvent être utilisés comme base pour faire des hypothèses et pour avoir une meilleure idée du type de logiciel le plus populaire parmi les traders.
Vous n'êtes pas encore inscrit en tant que développeur ?
Alors nous venons chez vous :)
En fait, tout le monde l'a remarqué et s'en réjouit en silence pour ne pas les faire fuir :)
Je ne suis pas d'accord avec tous les arguments de hrenfx, cependant, j'ai personnellement choisi MT5 uniquement pour la POO et la bibliothèque standard.
J'aimerais vraiment que, lors de l'introduction de la POO dans MT4++, le plus grand nombre possible d'interfaces de classes de la bibliothèque standard soit conservé (idéalement, toutes sauf les classes de négociation CTrade, CPositionInfo, qui concernent directement la compensation).
À propos, le bon vieux tableur dont il parle concernel'historique personnalisé - dans MT5, il est toujours possible de l'émuler - en utilisant simplement ces fonctionnalités.
Je me demande comment il est possible - d'émuler dans le testeur MT5 (c'est-à-dire de tester sur votre propre historique) ?
Où est-ce que ça dit ça ?
Je me demande comment ceci peut être émulé dans le testeur MT5 (i.e. tester sur votre historique) ?
Où est-ce que ça dit ça ?
Ça ne le dit nulle part. C'est mon idée. J'ai lancé un sujet sur ce forum, mais personne ne l'a soutenu, j'ai donc réalisé que personne ne s'y intéressait.
Si un conseiller expert n'utilise que des classes de la bibliothèque standard pour fonctionner, et n'utilise pas les fonctions d'accès direct au serveur, alors la tâche d'émulation consiste à écrire des classes dérivées des classes de la bibliothèque standard, qui ne s'appliqueraient pas au serveur, et utiliseraient leurs propres variables internes.
Ensuite, le conseiller expert reçoit non pas les classes originales de la bibliothèque standard, mais les classes dérivées qui, au lieu d'accéder au serveur, transmettent au conseiller expert les résultats de leurs propres calculs internes. Le conseiller expert ne remarque pas le changement - il ne se soucie pas de savoir avec quoi travailler - que ce soit sur les données réelles ou historiques.
Pour ma part, j'ai déjà écrit une classe-stockage de données historiques et des classes, héritières de timeseries (comme SOPrep, CHigh, etc.), qui peuvent retourner à l'EA à la fois des données réelles du serveur et des données historiques du stockage. Plus tard, j'écrirai des classes de trading en tant que descendantes des classes de la bibliothèque standard qui peuvent servir de "wrapper" pour les transactions du serveur réel et effectuer des transactions virtuelles basées sur des données historiques. Là encore, le conseiller expert ne sera pas au courant de la substitution.
Tout cela est possible. Même si, bien sûr, il y a beaucoup de travail à faire.
Ça ne le dit nulle part. C'était mon idée. J'ai lancé un fil de discussion sur le forum, mais personne ne l'a soutenu, je me suis rendu compte que personne ne s'y intéresse.
Si un conseiller expert n'utilise que des classes de la bibliothèque standard pour fonctionner, et n'utilise pas les fonctions d'accès direct au serveur, alors la tâche d'émulation consiste à écrire des classes dérivées des classes de la bibliothèque standard, qui ne s'appliqueraient pas au serveur, et utiliseraient leurs propres variables internes.
Ensuite, le conseiller expert reçoit non pas les classes originales de la bibliothèque standard, mais les classes dérivées qui, au lieu d'accéder au serveur, transmettent au conseiller expert les résultats de leurs propres calculs internes. Le conseiller expert ne remarque pas le changement - il ne se soucie pas de savoir avec quoi travailler - que ce soit sur les données réelles ou historiques.
Pour ma part, j'ai déjà écrit une classe-stockage de données historiques et des classes, héritières de timeseries (comme SOPrep, CHigh, etc.), qui peuvent retourner à l'EA à la fois des données réelles du serveur et des données historiques du stockage. Plus tard, j'écrirai des classes de trading en tant que descendantes des classes de la bibliothèque standard qui peuvent servir de "wrapper" pour les transactions du serveur réel et effectuer des transactions virtuelles basées sur des données historiques. Là encore, le conseiller expert ne sera pas au courant de la substitution.
Tout cela est possible. Bien sûr, il y a beaucoup de travail.
Si vous écrivez un indicateur qui lit les données d'un fichier (historique personnalisé), remplacez les fonctions standard de réception des données (à la fois les cotations et l'environnement du marché), utilisez une définition des contextes et vous serez heureux.
Je ne partage pas votre admiration pour la bibliothèque standard, c'est un énorme monstre avec la prétention d'être universel, créé uniquement pour des exemples et pour créer des Expert Advisors dans l'assistant.
Bien qu'il ait été conçu pour cela, il remplit très bien ses fonctions.
Vous devriez écrire un indicateur qui lit les données à partir d'un fichier (historique personnalisé), remplacer les fonctions standard d'acquisition de données (à la fois les cotations et l'environnement de marché), utiliser la définition des contextes et vous serez heureux.
C'est exactement ce que je fais. J'ai déjà écrit des classes qui peuvent passer à un EA l'historique personnalisé (au lieu de l'historique réel du serveur). Mais l'EA ne doit pas utiliser les fonctions du terminal directement pour la réalisation complète de mon idée. Disons, le même OrderSend(). Il ne doit fonctionner qu'à travers un "wrapper", dont le rôle peut être merveilleusement rempli par la bibliothèque standard. Nous écrivons des classes dérivées, les transmettons à l'EA, et voilà - il travaille maintenant sur des données historiques. Si l'EA utilise directement les fonctions du terminal, il ne sera pas en mesure d'utiliser l'historique.
Je ne partage pas votre admiration pour la bibliothèque standard, un énorme monstre qui prétend être universel et qui n'a été créé que pour les exemples et pour la création d'Expert Advisors dans l'assistant.
Mais il remplit très bien son rôle.
Eh bien, c'est peut-être l'effet de mon long travail avec la bibliothèque MFC dont j'ai été très satisfait et avec laquelle je trouve beaucoup de parallèles. Je suis sûr que les développeurs de la bibliothèque standard sont également très familiers avec MFC.
Le principal avantage de la bibliothèque standard est le bon support de l'idéologie OOP, qui permet de passer au conseiller expert un historique personnalisé afin qu'il fonctionne correctement sans aucune modification.
Puis-je vous demander pourquoi vous n'aimez pas la bibliothèque standard (en dehors de l'inconvénient évident - "paresseux à apprendre") ?
Pendant que nous examinions les détails techniques de la mise à niveau, nous avons perdu un détail important : le marché apparaîtra dans MetaTrader 4. Compte tenu de la prévalence de l'IV, nous pouvons estimer combien un développeur de robot/indicateur peut gagner sur le marché unifié de 7 millions de traders. MQL5 Les résultats du marché peuvent être utilisés comme base pour faire des hypothèses et pour avoir une meilleure idée du type de logiciel le plus populaire parmi les traders.
Vous êtes-vous déjà inscrit en tant que développeur ?
Maintenant que nous avons touché le marché, j'aimerais entendre quelques opinions sur un sujet...
Selon la philosophie de MQL5, les indicateurs doivent compter et les EA doivent trader.
Mais le Marché vend des solutions toutes faites, comme on dit, tout en un.
Peut-être faudrait-il améliorer le compilateur pour que les indicateurs soient stockés dans les conseillers experts en tant que ressources ?
Sinon, nous devons transférer le code de l'indicateur dans le conseiller expert, où il n'a pas d'environnement approprié. Là encore, le schéma "indicateur par indicateur" est toute une épopée pour transférer le code vers l'Expert Advisor.