Erreurs, bugs, questions - page 2754

[Ilyas]

A100:

Ce qui confirme une fois de plus qu'il est inutile d'utiliser directement _Digits,_Point , _Period, _LastError, etc. (et même _Symbol peut être remplacé par NULL). En fait, ils doivent être déclarés comme const volatile.

Et vous, au contraire, vous proposez d'élargir cet éventail

Vous avez raison, mais ils sontpresque volatiles, à l'exception de l'indicateur IsStopped - il est 100% volatile, c'est-à-dire que toute lecture de IsStopped est une lecture de la mémoire à 100%.
Pour d'autres,presquevollatylе signifie que le compilateur PEUT mettre en cache la valeur d'une variable dans un registre lors du premier appel et utiliser la valeur en cache lors du prochain accès à cette variable, mais uniquement dans une fonction ou une branche d'appels, si elles sont inlined dans une fonction.
Ceci est possible (et nécessaire) parce que la modification des variables prédéfinies (sauf IsStopped) ne peut pas se faire à l'intérieur d'un point d'entrée MQL (fonction OnXXX).

En ce qui concerne le MODIFICATEURVARIABLE, disons qu'il est utilisé par des programmeurs constants pour des programmeurs.
Comme nous le savons, vous pouvez changer la constante d'une variable par le biais d'une conversion, on ne peut donc pas faire confiance au compilateur avec le modificateur const.
Si le compilateur voit que la variable n'a pas changé de valeur et qu'elle est initialisée comme une constante, il transformera une telle variable en une valeur immédiate (ImmediateValue) même sans le modificateur const

. Concernant _LastTick, nous discutons mais...
Il s'agit d'une structure, pas d'un simple type atomique, et elle peut être modifiée soudainement, à n'importe quel moment du programme MQL, y compris au moment de l'obtention de la valeur.
Il s'avère que pour traiter cette structure, il faut introduire un synchroniseur.

Nous travaillons constamment sur les performances, notamment en raison de ce rythme de publication élevé des builds.
Nous prévoyons de faire beaucoup d'efforts pour accélérer le code MQL.

[Igor Makanu]

Ilyas:

En ce qui concerne _LastTick, nous discutons, mais...

Il s'agit d'une structure, et non d'un type atomique simple, et elle peut être modifiée soudainement, à n'importe quel moment du programme MQL, y compris au moment de l'obtention de la valeur.
Il s'avère que pour traiter cette structure, nous devons introduire un synchroniseur.

mais dans le testeur _LastTick ne peut pas changer à n'importe quel moment du programme MQL ?

si oui, alors donnez une telle solution seulement pour le testeur, où la vitesse des calculs est la plus importante.

[Alexey Navoykov]

Igor Makanu:

mais dans le testeur _LastTick ne peut pas changer à n'importe quel moment du programme MQL ?

si oui, alors donnez une telle solution uniquement pour le testeur où la vitesse de calcul est la plus importante.

Alors, qu'est-ce qui vous empêche de demander ce tick une fois dans le handler OnTick, et ensuite de travailler avec les données obtenues ? Cela ne coûte pratiquement rien. Pourquoi devrais-je le demander 100 fois (comme dans les tests ci-dessus), en créant artificiellement des freins sur une place égale ? Ainsi, le problème d'un code EA tordu est suggéré pour résoudre en compliquant le travail interne de MT. Ou avez-vous des mesures normales ?

[fxsaber]

Alexey Navoykov:
Alors, qu'est-ce qui vous empêche de demander une fois ce tick dans le handler OnTick et de travailler ensuite avec les données reçues ?

Les faibles qualifications des créateurs d'EE dont Market et Cloud sont chargés constituent un obstacle.

[Maxim Kuznetsov]

Alexey Navoykov:
Donc, qu'est-ce qui empêche de demander le tick une fois dans le handler OnTick, et de continuer à travailler avec les données reçues ? Cela ne coûte pratiquement rien. Pourquoi le redemander 100 fois (comme dans les tests ci-dessus), en créant artificiellement des freins sur place ? Ainsi, on propose de résoudre le problème d'un code EA tordu en compliquant le travail interne de MT. Ou avez-vous des mesures normales ?

Les événements à traiter par "OnTick" sont reçus de l'extérieur dans une file d'attente avec des priorités. Dans d'autres gestionnaires, il est utile de s'assurer qu'aucun nouvel événement de ce type ne s'est produit, sinon les données du tick précédent sont invalides ou périmées.

[Igor Makanu]

Alexey Navoykov:
Alors, qu'est-ce qui vous empêche de demander ce tick une fois dans le handler OnTick et de travailler ensuite avec les données résultantes ? C'est pratiquement inutile. Pourquoi s'embêter à le demander 100 fois (comme dans les tests ci-dessus), créant artificiellement un frein sur place.

C'est exactement ce que je fais dans le testeur

Alexey Navoykov:
C'est à dire que le problème d'un code EA tordu est censé être résolu en compliquant le fonctionnement interne de MT. Ou avez-vous des mesures normales ?

Eh bien, le code est déterminé par des pratiques de codage communes, regardez le QB et l'utilisation des lignes de sécurité dans ces exemples

Je n'utilise pas SB, je mesure avec un profileur et je cherche des solutions depuis des mois, il y a eu un fil de discussion sur les tests de vitesse, avec des solutions alternatives.

la normalité du comptage ? c'est une pente glissante qu'il faudra traiter sérieusement, je suis content de mon EA pour l'optimisation, il y avait un passage à 18 mois 6 sec, maintenant 2.5 sec , imho j'ai fait un bon travail sur moi-même ))))

[A100]

Selon les matériaux de .... les considérations suivantes sont apparues :

Étant donné que UninitializeReason() peut être appelé dans n'importe quelle partie d'un programme, en particulier dans OnInit() (et si un tel appel n'était pas prévu, la portée pourrait être étendue)

Il est suggéré :

Si la valeur de la variable _UninitReason est générée avant l'appel de OnDeinit(),

et si le motif de la désinitialisation précédente de l'EA ne peut être défini (REASON_PROGRAM, REASON_REMOVE, etc.)

il devrait être indéfini (-1) avant cet appel. Elle est maintenant égale à 0, c'est-à-dire qu'effectivement REASON_PROGRAMME

Si l'EA est complètement redémarré(REASON_RECOMPILE, REASON_ACCOUNT, REASON_CLOSE, etc.), alors

il semble possible de définir la variable _UninitReason à une valeur appropriée (REASON_RECOMPILE, REASON_ACCOUNT, REASON_CLOSE, etc.) lors du démarrage d'une nouvelle instance d'un programme,

et non 0 comme actuellement, c'est-à-dire qu'effectivement REASON_PROGRAMME

Si un Expert Advisor est partiellement redémarré (REASON_CHARTCHANGE, etc.), la variable _UninitReason dans OnInit() est toujours égale à la valeur correspondante (REASON_CHARTCHANGE, etc.),

et aucun changement n'est nécessaire

[Sergey Dzyublik]

bug MT5 (build 2450) erreur de compilation pour la déclaration directe d'une méthode de classe modèle.

template<typename T>
class A{};


class B{
public:
   template<typename T>
   void test(A<T> &a);
};

template<typename T>
void B::test(A<T> &a){}   // 'test' - member function already defined with different parameters 


void OnStart(){ 
   B b;
} 

[Artyom Trishkin]

Lors du redémarrage du terminal, il écrit continuellement et sans interruption dans le journal des enregistrements.

2020.05.24 03:36:03.342 HistoryBase     'GBPUSD' 1 invalid bars removed

Le temps de la barre d'historique dans le journal est en constante augmentation. GBPUSD Le graphique quotidien est ouvert et s'agite - zéro, la première et la deuxième barre sont supprimées/créées. Et c'est ainsi que ça tourne en rond.

Je suis là à attendre. Est-ce qu'elle remplira toute la SSD avec ces bûches ou est-ce qu'elle s'arrêtera enfin...

Le journal d'hier est dans la remorque.

[Alexey Navoykov]

Erreur de compilation. Fonctionne bien dans les anciennes versions.

struct A { };

template<typename T> 
struct B : T { };  // 'A' - unexpected token

struct C : B<A> { };