Apprendre et écrire ensemble en MQL5 - page 19
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
(Oui et la demande, désolée peu justifiée et étayée par des arguments convaincants).
PS
Cependant, il se peut que j'aie manqué quelque chose et que les développeurs décident que c'est tout à fait raisonnable.
Je répète : il n'y a pas eu de demande aux développeurs :) Il n'y avait pas d'exigences ni même de demandes - en accord avec le thème de la branche. Comme le dit l'adage : "navigué, on sait" :) La raison que j'ai expliquée ici :"Si quelqu'un posait une telle question il y a six mois, on pourrait encore espérer une apparition relativement rapide de la fonctionnalité, mais en attendant l'année suivante, il est plus facile d'introduire une variable pour la date. Certes, elle ne sera pas tout à fait exacte, mais quand même.
Comme toujours, merci à tous pour vos réflexions ! Cette fois, vous m'avez convaincu que j'avais raison :)
stringo:
Question. La description de switch(expression){...} indique que "l'expression de l'opérateur switch doit être de type entier". J'ai vu la description de cet opérateur avec des expressions d'autres types sur Internet. Allons-nous étendre l'utilisation de l'opérateur switch en ajoutant des expressions de type chaîne de caractères ?
Non, malheureusement, ce ne sera pas le cas. Pour les types de chaînes de caractères, seulement si ... sinon si ... autre .
L'utilisation de types entiers dans switch accélérera l'opérateur de switch plusieurs fois plus que si
Question. Y a-t-il (par analogie avec switch) un gain de vitesse par rapport à if de l'"opérateur conditionnel ? :"?
Question. Existe-t-il (comme pour le switch) une accélération par rapport au if pour"l'opérateur conditionnel ? :" ?
Non. L'opérateur conditionnel n'a pas d'accélération par rapport à if. C'est juste plus facile à écrire.
LIMITE_TYPE_D'ACHAT_STOP_DE_L'ORDRE
Lorsque le prix de l'ordre est atteint , un ordre d'achat limite en attente est placé au prix StopLimit.
Il semble que le traitement de cet ordre, y compris la définition d'un ordre d'achat limite en attente, soit effectué côté serveur. J'ai quelques questions auxquelles je n'ai pas trouvé de réponses dans la référence :
1) Est-ce queORDER_TYPE_BUY_STOP_LIMIT lui-même entre dans l'historiquelorsque le prix de l'ordre est atteint et que l'ordre d'achat limite en attente est placé ?
2) Le ticket d'un ordreORDER_TYPE_BUY_STOP_LIMIT est-il hérité par unnouvel ordre en attente placé côté serveur?
3) Un événement Trade est-il généré lorsqu'un ordre d'achat limite en attente côté serveur est placé ?
4) Comment (par quelle règle) l'heure d'expiration, la durée de vie de l'ordre et le commentaire sont-ils attribués à un nouvel ordre d'achat limité en attente, côté serveur ?
Et d'une manière générale, existe-t-il un moyen intelligent d'intercepter rapidement la passation de commandes du côté du serveur ? Cela a-t-il été mentionné quelque part ?
...
CopyTime(_Symbol,_Period,0,1,Old_Time) ;
Yedelkin:
...La fonction Sleep() ne ralentit pas le fil d'exécution lui-même.
Cela ralentit mais libère des ressources CPU pour d'autres threads.
C'est pourquoi vous ne devriez pas utiliser Sleep dans les indices - un thread peut calculer de nombreux indices et Sleep dans l'un d'entre eux rendra tous les autres inactifs également.
________
Mince, j'arrive trop tard :) la prochaine fois, je regarderai plus attentivement les dates.
Le fil n'est pas du tout lié au noyau.
Il ralentit mais libère les ressources du CPU pour d'autres threads.
C'est pourquoi Sleep ne devrait pas être utilisé dans les indulgateurs - un thread peut calculer un grand nombre d'indulgateurs et Sleep dans un thread entraînera tous les autres à être inactifs également.
________
Mince, j'arrive trop tard:) la prochaine fois, je regarderai plus attentivement les dates.
A propos de "tard". - C'est vrai ! L'expression clé ici est "libérer les ressources du CPU pour d'autres threads". C'est exactement ce que j'essayais de formuler dans la question.
LIMITE_TYPE_D'ACHAT_STOP_DE_L'ORDRE
Lorsque le prix de l'ordre est atteint , un ordre d'achat limite en attente est placé au prix StopLimit.
Il semble que le traitement de cet ordre, y compris la définition d'un ordre d'achat limite en attente, soit effectué côté serveur. J'ai plusieurs questions auxquelles je n'ai pas trouvé de réponses dans les documents de référence : ...
A en juger par le manque de réponses à la question, les gens ici sont post-MT4 et ne sont pas encore passés aux ordres stop-limite :)
Et, sans parler des paroles, j'ai trouvé sur Internet des documents affirmant qu'un ordre STOP LIMITE ne crée pas un nouvel ordre en suspens mais se transforme simplement en ordre limite lorsque certaines conditions sont remplies :
- un ordre conditionnel, qui se transforme en ordre à cours limité lorsque le prix du contrat atteint un certain niveau ;
- un ordre d'exécution d'une transaction à un prix inférieur au prix courant du marché, mais pas inférieur au prix spécifié dans la partie limite de l'ordre. Contrairement à un ordre stop, lorsque le prix du marché atteint le prix spécifié dans l'ordre, cet ordre est activé comme un ordre à cours limité. Dans ce cas, le prix d'exécution d'un ordre stop limite peut être soit égal au prix de l'ordre, soit supérieur à celui-ci ;
- un ordre client qui devient un ordre à cours limité lorsque le prix du marché atteint le niveau fixé (prix stop) ;
etc.
Cette approche répond à la plupart de mes questions. Mais si c'est effectivement le cas, alors la phrase du manuel concernant le "placement d'un ordre à cours limité" semble incorrecte et prête spécifiquement à confusion.