Erreurs, bugs, questions - page 313
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
Pour une raison quelconque, je ne peux pas obtenir le bénéfice du compte courant dans la fonction OnTester.
C'est ainsi que j'obtiens 0
double OnTester()
{
return(AccountInfoDouble(ACCOUNT_PROFIT));
}
Et c'est comme ça que je fais du profit :
double OnTester()
{
return(AccountInfoDouble(ACCOUNT_BALANCE)-100000);
}
Pourquoi on se dispute ? On ne met pas...
PS Il y a forcément un message (peut-être quelques lignes en dessous)
Glory Je suis d'accord - tous ces arguments sont tellement chronophages, qu'ils aillent se faire voir (arguments). :)
Mais alors, ce qu'on appelle sur la jambe - vous, je suis sûr, savez tout vous-même parfaitement, mais quand même, si cette fonction est externe et déclarée seulement par la déclaration, il y a des modificateurs tels que "const" et "in" et "out". Il y a peut-être un défaut dans cette fonction. Le problème est le suivant : s'il s'agit d'un paramètre retournable, un avertissement est donné s'il n'est pas retourné (s'il est retourné via "return") et, dans le cas d'une deuxième forme de fonction, lorsque la valeur de retour est retournée via le paramètre, un avertissement devrait également être donné, car il s'agit d'une valeur retournable. Sinon, si le résultat du succès/échec était renvoyé via un paramètre et que la valeur elle-même était renvoyée via return, ce serait impossible. Et le succès ou l'absence de succès est également TOUJOURS renvoyé. En d'autres termes - ( http://users.telenet.be/bart.demeyere/C++InOutParameters.html ) voici une solution qui existe depuis longtemps.
Mais la conversation en général, je n'ai rien remarqué. IMHO, vous devez répondre à de telles questions, si vous ne prévoyez pas de changer quoi que ce soit de fondamental dans l'implémentation actuelle quelque chose comme ça :) - "Oui, il y a un tel problème, il sera résolu dans les prochaines versions du programme, maintenant nous avons fixé le code, et nous ne faisons que corriger les erreurs". Personne (je pense que même les plus inadéquats) ne sera offensé, mais il est important et nécessaire de régler le problème lui-même.
Donc, qu'il y ait ou non dans cette version de tels modificateurs très ( TRÈS ) utiles dans out et autres, ils permettent significativement de minimiser les erreurs.
***
Il faudra une demi-journée pour faire toute cette correspondance. J'ai fini. :)
Pour une raison quelconque, je ne peux pas obtenir le bénéfice du compte courant dans la fonction OnTester.
C'est ainsi que j'obtiens 0
double OnTester()
{
return(AccountInfoDouble(ACCOUNT_PROFIT));
}
Et c'est comme ça que je fais du profit :
double OnTester()
{
return(AccountInfoDouble(ACCOUNT_BALANCE)-100000);
}
Déclarez une variable globale et affectez-lui la valeur actuelle du solde dans OnInit().
Dans OnTester(), calculez le bénéfice total en fonction des résultats de toutes les transactions effectuées :
et le sortir dans OnTester().
Et ce que vous essayez d'obtenir maintenant, c'est le profit non fixé actuel, qui est nul si toutes les positions sont fermées.
Glory Je suis d'accord - tous ces débats prennent tellement de temps qu'il ne faut pas s'en préoccuper (débats). :)
Y aura-t-il dans cette version des modificateurs très ( TRÈS ) utiles en sortie et autres, ils permettent de minimiser les erreurs.
"Pourquoi on se dispute ?" - est une phrase de mon enfance qui signifie "pourquoi se disputer ?
Passer un paramètre par référence est exactement ce que signifie inout. Il existe simplement des implémentations qui échappent au contrôle du compilateur.
En fait, il est assez facile d'analyser le flux d'exécution en entrant des fonctions (l'exemple fourni par Rashid). Nous avons délibérément refusé cette approche. La raison même était que cela augmenterait considérablement notre temps de compilation. C'est pourquoi nous avons choisi le moyen le plus simple : l'affichage d'un avertissement. Est-il préférable de ne pas produire un tel avertissement ? Oui, vous devriez. Si vous faites une initialisation explicite, il n'y aura pas d'avertissement.
Je répète également que nous avons un devis raccourci pour les expressions logiques. Cela signifie dans votre cas que si le premier ObjectGetDouble renvoie false (par exemple, parce que l'objet, remarquez l'externe au programme, n'existe soudainement pas), le deuxième ObjectGetDouble ne sera pas appelé
"Pourquoi on se dispute ?" - est une phrase de mon enfance qui signifie "pourquoi se disputer ?
Passer un paramètre par référence est exactement ce que signifie inout. Il existe simplement des implémentations qui échappent au contrôle du compilateur.
En fait, il est assez facile d'analyser le flux d'exécution en entrant des fonctions (l'exemple fourni par Rashid). Nous avons délibérément refusé cette approche. La raison même était que cela augmenterait considérablement notre temps de compilation. C'est pourquoi nous avons choisi le moyen le plus simple : l'affichage d'un avertissement. Est-il préférable de ne pas produire un tel avertissement ? Oui, vous devriez. Si vous faites une initialisation explicite, il n'y aura pas d'avertissement.
Je répète également que nous avons un devis raccourci pour les expressions logiques. Cela signifie dans votre cas que si le premier ObjectGetDouble renvoie false (par exemple, parce que l'objet, remarquez l'externe au programme, n'existe soudainement pas), le deuxième ObjectGetDouble ne sera pas appelé
C'est vrai, il ne sera pas appelé - c'est un comportement standard dans le code C.
Les modificateurs in et out peuvent s'ajouter aux références. Et par défaut, ils sont toujours en entrée et en sortie pour les références. Mais je peux passer une référence avec le modificateur in, ce qui signifie que le paramètre de cette fonction est toujours en entrée et qu'il est impossible d'y écrire, même s'il est passé par référence. Avez-vous lu ? http://users.telenet.be/bart.demeyere/C++InOutParameters.html
Il y a un modificateur const. Le passage d'une référence constante implique explicitement un paramètre in sans out. Nous n'introduirons certainement pas d'entités supplémentaires : in, out, inout...
Il y a un modificateur const. Le passage d'une référence constante implique explicitement un paramètre in sans out. Nous n'introduirons certainement pas d'entités supplémentaires : in, out, inout...
Si tu ne veux pas, tu ne veux pas. Mais vous devez savoir que vous n'obtiendrez pas une optimisation décente à ce moment-là. Et s'il y avait eu OUT dans cet exemple, l'avertissement n'aurait pas été généré. Mais tout cela en vain - IMHO - cela vous prendra trois minutes mais il y a beaucoup moins d'erreurs. Et si vous ne voulez pas l'utiliser, ne l'utilisez pas. Alors tout est comme il l'a toujours été. Comme maintenant. :)
Comment faire pour ne faire que du OUT sans du IN ? Ce qui veut dire que quelque chose est toujours retourné, tu sais, comme un retour de fonction ?
Les développeurs.
1. J'en déduis que le spread sur les principales paires a été martelé depuis mai 1993, soit environ 930 barres hebdomadaires à l'heure actuelle ?
Et dans l'histoire profonde, les bars ont été construits sur la base des jours.
Par conséquent, le conseiller expert peut être testé à partir de mai 1993 exactement (si nous utilisons un TF non inférieur à D1) ?
Peut-on regarder plus loin que le 9 mai 1993 sur le GBPUSD (comme il est mis en œuvre sur l'EURUSD) ?Bonjour.
Pouvez-vous expliquer pourquoi, lors de la création manuelle d'un objet"Graphic Tag", celui-ci ne dispose pas du fichier bmp spécifié pour les états on/off ?
Voici le code :
ObjectCreate(....) ;
.......
ObjectSetString(0, "ColorLabel", OBJPROP_BMPFILE, 0, "Images\on.bmp") ;
ObjectSetString(0, "ColorLabel", OBJPROP_BMPFILE, 1, "Images\off.bmp") ;
L'étiquette est créée tout à fait correctement, à la position spécifiée, avec les couleurs spécifiées, etc., mais les fichiers "Images\on.bmp" et "Images\off.bmp" ne sont pas spécifiés. Si dans le gui MT5
cliquez sur la liste des objets et définissez manuellement ces fichiers pour le marqueur, ils seront définis. Mais pourquoi ObjectSetString ne le fait-il pas ?
Qu'en pensez-vous ?
Qu'en pensez-vous ?
Essayez
ObjectSetString(0, "ColorLabel", OBJPROP_BMPFILE, 0, "\\Images\\on.bmp");
ObjectSetString(0, "ColorLabel", OBJPROP_BMPFILE, 1, "\\Images\\off.bmp");
Des changements seront bientôt apportés au certificat.