Attente : 2 ou (comme en C++) - erreur de compilation
Merci pour cet article !
MQL5 ne prend pas en charge le remplacement (et/ou le masquage) des méthodes de classe.
Si je me souviens bien, nous avons déjà discuté de cette fonctionnalité il y a plusieurs années, bien qu'il s'agissait de savoir quelle surcharge devait être appelée la plus proche en héritage ou plus exacte en termes de paramètres.
Dans la nouvelle version du compilateur, les surcharges fonctionneront comme en C++.
C'est-à-dire que lorsque vous surchargez une méthode parent, il ne sera possible de l'appeler qu'en utilisant "b.A::f()", une tentative d'appeler b.f(10) entraînera une erreur, la méthode b.f() - n'a pas de paramètre, et la méthode A::f(int) n'est pas disponible (cachée), car elle est surchargée.
La valeur retournée n'est pas le "prix d'ouverture" mais le" prix d'ouverturemoyen pondéré ".
A titre d'exemple :
Nous ouvrons une position pour 1 lot au prix de 61532. Dans ce cas, PriceOpen() retournera 61532.
Nous augmentons en outre notre position d'un lot à 61615. Dans ce cas, PriceOpen() retournera le prix moyen pondéré de deux lots 61573.5, et non le prix d'ouverture de la position.
J'aimerais voir non seulement une correction d'un seul mot dans la description, mais aussi une brève explication-illustration.
Le fait est que si vous augmentez une position jusqu'au montant qui ne peut être divisé sans le reste, les centimes sont divisés, et ils sont perdus lors de l'arrondi. Par conséquent, le solde ne s'additionne pas à la fin. Toutes les transactions sont effectuées en roubles strictement entiers, le solde final ne converge pas en raison des kopecks perdus.
Schéma de reproduction de l'erreur avec perte de kopecks dans la balance, même en trading manuel.
Je vais en outre expliquer ce qu'est l'erreur :
La colonne "A" correspond aux chiffres réels (prix des transactions). La colonne "B" est un dérivé de la colonne "A" avec une perte de précision. Tout comptable qualifié vous expliquera que le bilan ne doit être rapproché que des chiffres réels, et jamais des dérivés de perte de fidélité.
Le centime n'est pas seulement affiché de manière incorrecte dans le terminal, il se déplace réellement entre les comptes du client et du courtier. N'importe quel avocat ou agent fiscal vous dira qu'il s'agit d'une "escroquerie" et que cela pourrait faire l'objet d'un litige entre le trader et le courtier.
La mise en œuvre d'une correction après une période de temps considérable confirme l'affirmation selon laquelle les centimes sont réellement perdus. Quel genre de correction ? Pourquoi des volumes aussi étranges ?
Je veux évoquer à nouveau le "problème du prix moyen pondéré" dans la description de CPositionInfo, commande PriceOpen()
Allons voir ça.
Cela nous aidera beaucoup si vous nous donnez votre mot de passe d'investisseur temporairement dans votre compte personnel pour quelques heures. Nous voulons vérifier les prix et les éventuels arrondis dans votre tableau de transactions. Vous serez contacté.
Pour confirmer l'affirmation selon laquelle les centimes sont vraiment perdus, il faut effectuer une correction après un laps de temps significatif. Quel genre de correction ? Pourquoi dans des volumes aussi étranges ?
Cela nous aidera beaucoup si vous nous donnez votre mot de passe temporaire d'investisseur pour quelques heures. Nous voulons vérifier les prix et les éventuels arrondis dans votre feuille de calcul. Vous serez contacté par.
La correction est différente.
Courtier Otkritie
Serveur
: Open-Demo
Connexion
: 1010955
Mot de passe
: B7NhSEwx
Investisseur
: B7NhSEwx (mot de passe en lecture seule)
Dans la démo, le mot de passe de l'investisseur est le même que celui du compte, il n'y a donc aucune différence entre les deux.
Символ Сделки Sell Buy Символ Общая прибыль, USD Убыток, USD Прибыль, USD Символ Общая прибыль, pips Убыток, pips Прибыль, pips Точечные графики распределения MFE и MAE Для каждой открытой позиции в течение ее жизни записываются значения максимальной прибыли (MFE) и максимального убытка (MAE). Эти показатели дополнительно...
Si je me souviens bien, nous avons déjà discuté de cette fonctionnalité il y a plusieurs années, bien que nous discutions de la surcharge qui devrait être appelée le plus près par héritage ou plus exactement par paramètres.
Oui... Je me souviens... Le C++ utilise la surcharge d'héritage la plus proche - de sorte que les changements ultérieurs dans les classes de base (apparition d'une nouvelle surcharge de précision des paramètres) n'affectent pas l'ordre des calculs dans les classes dérivées (cette nouvelle surcharge ne serait pas invoquée).
Veuillez noter ce qui suit :
void f( int a, int b = 2 ); //(1)
//...void f( int a = 1, int b ); //(2) //Error: 'b' - missing default value for parameter//...void f( int a, int b ) {}
Cela semble être une bagatelle - il suffit d'écrire
void f( int a = 1, int b = 2 ); //(2) //нормально
et être heureux, mais le point est exactement, qu'il n'est pas nécessaire deux fois ou plus de temps pour écrire b = 2, et donc au changement ultérieur sur, disons : b = 3 - il sera nécessaire de changer seulement dans un endroit (et pas dans deux ou plus), et donc (en tenant compte de la distribution du programme) il est impossible d'oublier de le faire dans d'autres endroits
Est-il normal que les agents ne libèrent pas de RAM après une tâche dans le nuage ?
La question n'est pas complète. Combien de temps vos agents conservent-ils la mémoire ? Quelle est la construction du terminal ?
Erreur pendant l'exécution :
Résultat : 1
Attente : 2 ou (comme en C++) - erreur de compilation
Merci pour cet article !
MQL5 ne prend pas en charge le remplacement (et/ou le masquage) des méthodes de classe.
Si je me souviens bien, nous avons déjà discuté de cette fonctionnalité il y a plusieurs années, bien qu'il s'agissait de savoir quelle surcharge devait être appelée la plus proche en héritage ou plus exacte en termes de paramètres.
Dans la nouvelle version du compilateur, les surcharges fonctionneront comme en C++.
C'est-à-dire que lorsque vous surchargez une méthode parent, il ne sera possible de l'appeler qu'en utilisant "b.A::f()", une tentative d'appeler b.f(10) entraînera une erreur, la méthode b.f() - n'a pas de paramètre, et la méthode A::f(int) n'est pas disponible (cachée), car elle est surchargée.
La question n'est pas complète. Combien de temps vos agents gardent-ils la mémoire ? Quelle est la construction du terminal ?
Modifiez-le.
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégies de trading
Bugs, bugs, questions
SEM, 2019.07.01 09:03
Est-il normal que les agents ne libèrent pas la RAM après avoir effectué une tâche dans le nuage ?
Version 2085, 13 juin 2019.
Tient la RAM pendant au moins une heure.
Je veux faire remonter le "problème du prix moyen pondéré" dans la description de CPositionInfo, commande PriceOpen()
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie
Service Desk. Plaintes, suggestions.
Francuz, 2019.06.13 11:36
Erreur dans la description de la bibliothèque standard
Plus précisément, dans la description de CPositionInfo, la commande PriceOpen()
https://www.mql5.com/ru/docs/standardlibrary/tradeclasses/cpositioninfo/cpositioninfopriceopen
La valeur retournée n'est pas le "prix d'ouverture" mais le" prix d'ouverturemoyen pondéré ".
A titre d'exemple :
Nous ouvrons une position pour 1 lot au prix de 61532. Dans ce cas, PriceOpen() retournera 61532.
Nous augmentons en outre notre position d'un lot à 61615. Dans ce cas, PriceOpen() retournera le prix moyen pondéré de deux lots 61573.5, et non le prix d'ouverture de la position.
J'aimerais voir non seulement une correction d'un seul mot dans la description, mais aussi une brève explication-illustration.
Le problème duprix d' ouverturemoyen pondéré a des conséquences désagréables.
Le fait est que si vous augmentez une position jusqu'au montant qui ne peut être divisé sans le reste, les centimes sont divisés, et ils sont perdus lors de l'arrondi. Par conséquent, le solde ne s'additionne pas à la fin. Toutes les transactions sont effectuées en roubles strictement entiers, le solde final ne converge pas en raison des kopecks perdus.
Schéma de reproduction de l'erreur avec perte de kopecks dans la balance, même en trading manuel.
Je vais en outre expliquer ce qu'est l'erreur :
La colonne "A" correspond aux chiffres réels (prix des transactions). La colonne "B" est un dérivé de la colonne "A" avec une perte de précision. Tout comptable qualifié vous expliquera que le bilan ne doit être rapproché que des chiffres réels, et jamais des dérivés de perte de fidélité.
Le centime n'est pas seulement affiché de manière incorrecte dans le terminal, il se déplace réellement entre les comptes du client et du courtier. N'importe quel avocat ou agent fiscal vous dira qu'il s'agit d'une "escroquerie" et que cela pourrait faire l'objet d'un litige entre le trader et le courtier.
La mise en œuvre d'une correction après une période de temps considérable confirme l'affirmation selon laquelle les centimes sont réellement perdus. Quel genre de correction ? Pourquoi des volumes aussi étranges ?
Je veux évoquer à nouveau le "problème du prix moyen pondéré" dans la description de CPositionInfo, commande PriceOpen()
Allons voir ça.
Cela nous aidera beaucoup si vous nous donnez votre mot de passe d'investisseur temporairement dans votre compte personnel pour quelques heures. Nous voulons vérifier les prix et les éventuels arrondis dans votre tableau de transactions. Vous serez contacté.
Une correction est différente.
Allons voir ça.
Cela nous aidera beaucoup si vous nous donnez votre mot de passe temporaire d'investisseur pour quelques heures. Nous voulons vérifier les prix et les éventuels arrondis dans votre feuille de calcul. Vous serez contacté par.
La correction est différente.
Courtier Otkritie
Sur la piste: https://www.mql5.com/ru/signals/596871
Si je me souviens bien, nous avons déjà discuté de cette fonctionnalité il y a plusieurs années, bien que nous discutions de la surcharge qui devrait être appelée le plus près par héritage ou plus exactement par paramètres.
Oui... Je me souviens... Le C++ utilise la surcharge d'héritage la plus proche - de sorte que les changements ultérieurs dans les classes de base (apparition d'une nouvelle surcharge de précision des paramètres) n'affectent pas l'ordre des calculs dans les classes dérivées (cette nouvelle surcharge ne serait pas invoquée).
Veuillez noter ce qui suit :
Cela semble être une bagatelle - il suffit d'écrire
et être heureux, mais le point est exactement, qu'il n'est pas nécessaire deux fois ou plus de temps pour écrire b = 2, et donc au changement ultérieur sur, disons : b = 3 - il sera nécessaire de changer seulement dans un endroit (et pas dans deux ou plus), et donc (en tenant compte de la distribution du programme) il est impossible d'oublier de le faire dans d'autres endroits
Aide
ERR_INDICATEUR_DATA_NOT_FOUND
4806
Données demandées non trouvées
En même temps, l'indicateur sur le graphique s'affiche normalement.
Que dois-je faire ?
Où creuser ?
Nécessité d'attendre - le box est occupé (données non calculées au moment du contact)