Caractéristiques du langage mql4, subtilités et techniques - page 14

[Alexander Dubovik]

Note aux développeurs.

https://docs.mql4.com/ru/basis/types/integer

La norme C++ ne garantit que la taille du type char. Les longueurs des autres types sont spécifiques à la mise en œuvre. La table de correspondance est incorrecte et peut entraîner un comportement non défini.

[Artyom Trishkin]

Les commentaires non liés à ce sujet ont été déplacés vers "Questions des débutants de MQL4 MT4 MetaTrader 4".

[fxsaber]

Forum sur le trading, les systèmes de trading automatisés et les tests de stratégies de trading

Bugs, bugs, questions

fxsaber, 2018.12.01 11:15

Conception du super-frein

string Str[];
const int handle = FileOpen(FileName, FILE_READ | FILE_ANSI | FILE_TXT);  

FileReadArray(handle, Str);

Un fichier de 40 Mo contenant 1 million de lignes prend 18 secondes à lire.

Le même résultat de sortie, mais fait différemment

  uchar Bytes[];
  const int handle = FileOpen(FileName, FILE_READ | FILE_BIN);
  
  FileReadArray(handle, Bytes);

  string Str[];
  StringSplit(CharArrayToString(Bytes), '\n', Str);

est déjà fait en 0,5 seconde.

[fxsaber]

Surcharge de 16Gb RAM avec des tâches. Chrome a fini par geler, MT5 avec l'optimisation en cours - pas de problème. Mais MT4 est plus intéressant.

Les indicateurs fonctionnent toujours, mais les conseillers experts se sont arrêtés à cause du message "out of range" dû à l'absence de vérification du résultat de ArrayResize.

Je ne veux pas toujours vérifier ArrayResize mais voici une confirmation que l'absence de cette vérification peut arrêter, par exemple, un Expert Advisor de combat sur VPS.

La seule chose que je n'arrive pas à comprendre est comment le résultat est "hors de portée" si ArrayResize a été fait précédemment avec une grande réserve ?

[Maxim Kuznetsov]

fxsaber:

Surcharge de 16Gb RAM avec des tâches. Chrome a fini par geler, MT5 avec l'optimisation en cours - pas de problème. Mais MT4 est plus intéressant.

Les indicateurs fonctionnent toujours, mais les conseillers experts se sont arrêtés en raison de l'absence de vérification du résultat d'ArrayResize.

Je ne veux pas toujours vérifier ArrayResize mais voici une confirmation que l'absence de cette vérification peut arrêter, par exemple, un Expert Advisor de combat sur VPS.

La seule chose que je n'arrive pas à comprendre, c'est comment il est devenu "hors de portée" si ArrayResize a été fait précédemment avec une grande réserve ?

facile :-) ceci est vrai pour la plupart des langues/systèmes.

La réserve allouait de la mémoire virtuelle et lorsque j'étais à court de mémoire physique, je ne trouvais pas de page libre. Nous avons obtenu une exception du processeur qui, après une série de traitements, s'est transformée en un dépassement de gamme.

D'ailleurs, le fait que MT ne se soit pas planté du tout confirme la qualité de la fabrication :-)

[fxsaber]

Erreur grossière sur le sujet du tri sélectif dans l'histoire. Le tri par heure de fermeture n'est pas toujours possible, malheureusement.

Vérification du script

#property strict

void OnStart()
{
  datetime time = INT_MAX;
  
  for (int i = OrdersHistoryTotal() - 1; i >= 0; i--)
    if (OrderSelect(i, SELECT_BY_POS, MODE_HISTORY))
    {
      if (OrderCloseTime() > time)
      {
        Print(time);
        OrderPrint();
        
//        break;
      }
      
      time = OrderCloseTime();
    }
}

La raison pour laquelle un code aussi élémentaire ne pouvait pas être écrit immédiatement pour l'auto-test est un mystère.

C'est aussi une énigme : comment se fait-il que les commandes ne soient pas triées par heure ? Je pose cette question car j'ai utilisé un testeur personnalisé dans un QB. Et logiquement, puisque l'ordre est entré dans l'histoire, l'enregistrement de celui-ci y est plus tardif que ceux qui y sont entrés avant. La façon d'ébranler cette logique n'est pas du tout claire.

Il se peut que les ordres soient stockés sur différents serveurs MT5 et que ce désordre se produise lors de la synchronisation. J'espère qu'il s'agit d'un bug du Terminal et non du serveur MT4. J'espère également que cela ne se produira pas avec les transactions dans MT.

[Artyom Trishkin]

fxsaber:

Erreur grossière sur le sujet du tri sélectif dans l'histoire. Le tri par heure de fermeture n'est pas toujours possible, malheureusement.

Vérification du script

La raison pour laquelle un code aussi élémentaire ne pouvait pas être écrit immédiatement pour l'auto-test est un mystère.

C'est aussi une énigme : comment se fait-il que les commandes ne soient pas triées par heure ? Je pose cette question car j'ai utilisé un testeur personnalisé dans un QB. Et logiquement, puisque l'ordre est entré dans l'histoire, l'enregistrement de celui-ci y est plus tardif que ceux qui y sont entrés avant. La façon d'ébranler cette logique n'est pas du tout claire.

Il se peut que les ordres soient stockés sur différents serveurs MT5 et que ce désordre se produise lors de la synchronisation. J'espère qu'il s'agit d'un bug du Terminal et non du serveur MT4. J'espère également que cela ne se produira pas avec les transactions dans MT.

Avez-vous essayé de modifier le tri dans l'historique du compte ?

[fxsaber]

Artyom Trishkin:

Avez-vous essayé de modifier le tri dans l'historique du compte ?

Ça n'affecte pas le résultat.

[Ihor Herasko]

Artyom Trishkin:

Avez-vous essayé de modifier le tri dans l'historique du compte ?

Oui, cela ne devrait avoir aucun effet. Seul le nombre de commandes dans l'onglet "Historique du compte" est affecté. Vous devez garder un œil sur ça.

[Алексей Тарабанов]

fxsaber:

N'affecte pas le résultat.

L'heure de fermeture de la position est donnée par le serveur.