Toute question des nouveaux arrivants sur MQL4 et MQL5, aide et discussion sur les algorithmes et les codes. - page 520
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
Quel est l'intérêt d'une telle construction ?
Ou est-il préférable de faire dedatetime un type long ?
Mais il y a un besoin évident de précision (datetime est plus grand que time_t, pour ne pas dire plus).
et il devrait plutôt être long pour les comparaisons de temps. Si le compilateur optimise quelque chose, il le jette, et il reste un dépôt pour l'avenir :-)
Je ne vois pas de problème jusqu'à présent.
Mais il y a une tendance évidente à être plus précis (datetime est doucement plus grand que time_t)
et il est plus probable que cette longue soit utilisée pour comparer les temps. Si le compilateur optimise quelque chose, il le jettera et laissera un dépôt pour le futur :-)
Donc vous pouvez l'utiliser sans tricher sans conséquences ?
Donc vous pouvez l'utiliser sans tricher sans conséquences ?
Eh bien, comment pourrait-il en être autrement sans conséquences :-)
long x = TimeCurrent(); reçoit déjà une "claque sur le visage" dans une bonne entreprise :-) Non seulement les types sont différents en physique, mais ils sont également différents en dimension et vous convertissez un type plus grand en un plus petit.
Mais oui, toutes les secondes de (datetime)TimeCurrent semblent s'adapter à une longue durée.
il existe une excellente fonction StringFind() - recherche l'occurrence de la chaîne "#" ou immédiatement "de #".
et qu'en faisons-nous ?
DansStringSubstr, tout est clair, vous obtenez les chiffres immédiatement - ticket, mais ici dansStringFind , nous savons déjà qu'il y a"à #" dans le commentaire
Trouvé
et que faire avec ?
DansStringSubstr tout est clair, nous obtenons les chiffres immédiatement - ticket, mais ici dansStringFind quoi, nous savons déjà qu'il ya"à #" dans le commentaire
mais on ne sait pas où.) StringFind nous dira si le "à #" que nous recherchons se trouve à cette position ou pas du tout. Ne vous fiez jamais à quelque chose qui vient du net et que vous ne contrôlez pas personnellement :-) Nous jouons de l'argent ici - c'est sérieux.
mais je ne sais pas où :-) StringFind vous dira que le "à #" que vous recherchez se trouve exactement à cette position, ou qu'il n'existe pas du tout. Ne vous fiez jamais à quelque chose qui vient du net et que vous ne contrôlez pas personnellement :-) Nous jouons de l'argent ici - c'est sérieux.
il faut mettre en évidence le ticket du commentaire et jeter le "à #".
le ticket pour une position ouverte est comparé à celui du commentaire pour une position fermée
pourquoi cherchons-nous le "to #" ?
La fonctionStringSubstr renvoie la partie droite du commentaire. Pourquoi cette fonction renvoie-t-elle le bénéfice d'une position ouverte et non le bénéfice d'une position fermée ? Je passe parMODE_HISTORY
Où est le mal dans une telle conception ?
Ou est-il préférable de faire dedatetime un type long ?
Le ticket doit être mis en évidence dans le commentaire et le"à #" doit être supprimé.
le ticket pour une position ouverte doit être comparé au ticket dans le commentaire pour une position fermée
pourquoi cherchons-nous le"to #" ?
Nous le recherchons afin de savoir "s'il y a même un to# ou un from#" dans le commentaire. Si ce n'est pas le cas, alors cet ordre ne fait pas partie d'une position fermée et nous n'en avons pas besoin.
Si le StringFind(OrderComment(), "#to") est supérieur ou égal à zéro, cela signifie que le commentaire contient la sous-chaîne recherchée, et seulement maintenant nous pouvons calculer la position du numéro de ticket dans cette chaîne.
La fonctionStringSubstr renvoie la partie droite du commentaire. Pourquoi cette fonction renvoie-t-elle le bénéfice d'une position ouverte et non le bénéfice d'une position fermée ? Je passe parMODE_HISTORY.
Et voici la réponse à cette question.
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie
Toutes les questions des débutants sur MQL4, aide et discussion sur les algorithmes et les codes
PolarSeaman, 2018.04.07 00:25
TrouvéEt qu'en faire ?
Tout est clair dansStringSubstr, vous obtenez des chiffres - ticket, mais ici dansStringFind quoi, nous savons déjà qu'il y a"à #" dans le commentaire
Mais si vous ne le faites pas, vous obtiendrez quelque chose de complètement différent.