Erreurs, bugs, questions - page 2202

[Sergey Dzyublik]

Un objet de synchronisation avec une surcharge plus importante que ce que le fichier ne pouvait pas offrir ? Conneries.

[Konstantin]

Alexey Navoykov:

Oui, il y a un tel problème. Quand on passe un pointeur par référence à un opérateur surchargé, une erreur se produit. Cela est apparu dans les dernières versions, tout était OK avant. J'ai envoyé une demande au service-desk depuis deux mois maintenant, mais il est silencieux comme d'habitude. Aucune réponse ou au revoir.

Ceci est particulièrement critique pour les tableaux de pointeurs, car il n'y a pas d'autre moyen de les envoyer, sauf par référence :

Donc, je suis toujours assis sur 1554 construire.

J'ai été confronté au même problème avec les pointeurs dans les dernières versions, avant il était possible de passer void sans problème, maintenant par référence cela ne fonctionne pas, j'ai dû corriger le code dans plusieurs de mes bibliothèques.

[Konstantin]

Sergey Dzyublik:
Un objet de synchronisation avec une surcharge plus importante que ce que le fichier ne pouvait pas offrir ? Conneries.

Est-il même nécessaire d'écrire dans un fichier pendant les tests ? Quel est le problème avec la mémoire ?

[romachandr]

Alexey Navoykov:

Merci pour l'astuce concernant Sleep() de Kernel!

[romachandr]

Комбинатор:
Pourquoi est-ce si difficile de le faire ? Gardez un œil sur le fichier de résultat + Sleep natif résout le problème.

Pendant le test, MQL Sleep() saute le temps virtuel (c'est-à-dire qu'il décale le temps de 0,6 seconde) alors que le temps réel saute moins d'une milliseconde et que le programme externe s'exécute en temps réel.

Mais avec Sleep from Kernel, je vais essayer).

[romachandr]

Konstantin:

est-il même nécessaire d'écrire dans un fichier pendant les tests ? qu'est-ce qui ne va pas avec la mémoire ?

Oui, le fait d'utiliser la mémoire au lieu d'écrire dans un fichier pendant les tests permet de gagner un peu de temps (je n'ai pas estimé exactement, mais je suppose jusqu'à 30 millisecondes maximum par cycle), mais c'est toujours le programme externe qui prend le plus de temps.

Pour l'instant, l'essentiel est donc de suspendre les tests pendant que le programme externe est en cours d'exécution.

[Konstantin]

romachandr:

Oui, l'utilisation de la mémoire au lieu de l'écriture dans un fichier pendant les tests permet de gagner un peu de temps (je n'ai pas estimé exactement, mais je suppose jusqu'à 30 millisecondes au maximum par cycle), mais la majeure partie du temps est toujours consacrée à l'exécution du programme externe.

Pour l'instant, l'essentiel est donc de suspendre les tests pendant que le programme externe est en cours d'exécution.

En général, la vitesse d'écriture dans un fichier et en mémoire diffère d'un facteur deux.

[pavlick_]

romachandr, il semble que j'ai mal compris la tâche. Je n'utilise pas de testeur, et je ne suis pas sûr que l'arrêt de l'EA arrête la génération de ticks. Je suis incompétent ici.

[A100]

Et maintenant (build 1809) vice versa

https://www.mql5.com/ru/forum/1111/page2181#comment_6765277

La 3ème ligne (dans OnStart) compile, mais la 4ème ligne ne compile pas.

En d'autres termes

typedef int (*fn)( uint ); 
#import "Test1.ex5"
        void f( fn );
#import "Test2.ex5"
        int g(  int ); //(1)
        int g( uint ); //(2)
#import
void OnStart()
{
        f( g ); //Error: 'g' - cannot resolve function address
}

Et si vous intervertissez les lignes (1) et (2), c'est bon. Quelle est la différence ?

[A100]

Texte excessif du message d'erreur

struct A final {
        void f1() { Print( __FUNCTION__ ); }
        void f2() {}
        void f3() {}
};
struct B : A {};
//комментарий

toutes les méthodes sont listées, et avec la mise en œuvre et les commentaires extérieurs