Erreurs, bugs, questions - page 1205

 

vide, sans un seul indicateur et terminal EA, même chose...

 
Renat:

Capturez les indicateurs et les EA en cours d'exécution pièce par pièce pour voir quel est le problème.

Cliquez sur le bouton "Détails" dans la fenêtre de description de l'erreur pour obtenir des détails. Copiez le texte complet ici, s'il vous plaît.

Je suppose que vous le voulez ?

crash --> 000007FCE8441F4F 48396B10 cmp [rbx+0x10], rbp

000007FCE8441F53 7530 jnz 0x7fce8441f85


000007FCE8441F55 488B03 mov rax, [rbx]

000007FCE8441F58 4C8BCF mov r9, rdi

000007FCE8441F5B 4D8BC7 mov r8, r15

000007FCE8441F5E 8BD6 mov edx, esi

000007FCE8441F60 488BCB mov rcx, rbx


: #021 00000000000011C8 EIP : 0000000000000000 ESP : 00000000000000000000


: #022 0000000000001068 EIP : 000007FCF54245DB ESP : 0000006818CFFAC8

000007FCF54245D1:00000A [000007FCF54245DB] NtYieldExecution (ntdll.dll)

000007FCF5426E50:000833 [000007FCF5427683] RtlUnicodeStringToInteger (ntdll.dll)

000007FCF3681828:00001A [000007FCF3681842] BaseThreadInitThunk(kernel32.dll)

000007FCF54774E8:000021 [000007FCF5477509] RtlVerifyVersionInfo (ntdll.dll)


: #023 000000000000111C EIP : 000007FCF54245DB ESP : 0000006818E5FB18

000007FCF54245D1:00000A [000007FCF54245DB] NtYieldExecution (ntdll.dll)

000007FCF5426E50:000833 [000007FCF5427683] RtlUnicodeStringToInteger (ntdll.dll)

000007FCF3681828:00001A [000007FCF3681842] BaseThreadInitThunk (kernel32.dll)

000007FCF54774E8:000021 [000007FCF5477509] RtlVerifyVersionInfo (ntdll.dll)

 
J'ai envoyé le texte complet par message privé
 

En analysant l'exemple précédent, nous avons découvert une différence cruciale entre MQL et C++.

class A {};
class B : public A {};
class C {
public:
        virtual int g( A* a ) { return ( 1 ); }
        virtual int g( B* b ) { return ( 2 ); } //здесь полное совпадение
};
class D : public C {
public:
        virtual int g( A* a ) { return ( 3 ); }
};
void OnStart()
{
        B* b = new B;
        D* d = new D;
        Print( d.g( b ));
}

En MQL(build 978) le résultat est : 2 (C::g est appelé), et en C++ le résultat est : 3 (D::g est appelé)

Il s'avère donc que MQL donne la priorité à une correspondance exacte du type de l'argument, même s'il est dans une classe de base, alors que C++ donne la priorité à la classe la plus proche possible qui peut ne pas avoir une correspondance exacte du type mais peut avoir une conversion implicite du type.

Veuillez vérifier les résultats sur des compilateurs C++ récents et, si la différence est confirmée, décidez de préférence en faveur du C++ à des fins d'unification.

 
ozhiganov:
J'ai envoyé le texte complet dans un message privé.
Merci, nous allons nous pencher sur la question.
 

Le constructeur de copie et l'opérateur d'affectation sont-ils même prévus dans le futur ?

La classe de base A a 15 champs, elle a deux descendants B et C - chacun a +5 champs supplémentaires.

Et le reste est une quête de 20 minutes.

 

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

Bugs, bugs, questions

A100, 2014.08.29 16:28

Erreur lors de la sortie via Print(...)

void OnStart()
{
        const int n = 300;
        Print( "n=", n );
        for ( int i = 0; i < n; i++ )
        {
                Print( i );
                if ( i == 0 )
                        Sleep( 2000 );
        }
}

lors de l'impression, la première partie de la sortie saute de 1 à 53 (chaque fois une partie différente - pas de schéma clair), parfois au milieu.

puis imprime jusqu'à 299 sans saut de page

Si vous avez un peu de temps, essayez de l'exécuter et si vous constatez des sauts dans les résultats, écrivez-moi. S'il n'y a pas de sauts - essayez d'augmenter n (j'ai commencé à sauter à n >= 300) et/ou de supprimer

        if ( i == 0 )
                Sleep( 2000 );

Sur demande #1060016 | 2014.08.29 16:30https://www.mql5.com/ru/users/A100/servicedesk/closed/14774

Une question s'est posée : "Comment puis-je informer d'un saut d'impression ?" - L'option la plus simple est une ligne unique avec une ligne pointillée à la place des lignes sautées

Lorsque l'utilisateur voit cette ligne, il comprend qu'il y a des omissions et doit se référer au fichier .log (les numéros de ligne ne sont pas nécessaires - juste à titre d'exemple).
 
A100:

En analysant l'exemple précédent, nous avons découvert une différence cruciale entre MQL et C++.

En MQL(build 978) le résultat est : 2 (C::g est appelé), et en C++ le résultat est : 3 (D::g est appelé)

Il s'avère donc que MQL donne la priorité à une correspondance exacte du type de l'argument, même s'il est dans une classe de base, alors que C++ donne la priorité à la classe la plus proche possible qui peut ne pas avoir une correspondance exacte du type mais peut avoir une conversion implicite du type.

Veuillez vérifier les résultats sur des compilateurs C++ récents et, si la différence est confirmée, décidez de préférence en faveur du C++ à des fins d'unification.

C'est vrai. La priorité est donnée à une correspondance exacte. Et c'est vraiment bien.

Pourquoi avons-nous besoin d'une telle unification ? Unification du traitement des programmes mal conçus

 
ALXIMIKS:

Le constructeur de copie et l'opérateur d'affectation sont-ils même prévus dans le futur ?

La classe de base A a 15 champs, elle a deux descendants B et C - chacun a +5 champs supplémentaires.

Et le reste est une quête de 20 minutes.

Oui, nous le ferons, mais dans un avenir proche, ce n'est pas dans les plans.
 
stringo:

C'est vrai. La priorité est donnée à la correspondance exacte. Et c'est vraiment bien.

Pourquoi avez-vous besoin d'une telle unification ? Unification du traitement des programmes mal conçus

Une unification est nécessaire pour que le même code fonctionne aussi bien avec C++ qu'avec MQL. En C++, cet ordre est fait ( !) pour une raison (sinon il y a des ambiguïtés à un moment donné). A l'origine, je pensais que le compilateur C++ était illogique et/ou avait un bug, mais maintenant je suis enclin à croire qu'il existe des raisons objectives pour une telle approche. Voici un exemple en MQL, qui montre que X: : g est une correspondance complète, mais que Y::g est quand même appelé - comme en C++, ce qui contredit l'exemple précédent https://www.mql5.com/ru/forum/1111/page1223#comment_1074757.

class A {};
class B : public A {};
class C : public B {};
class X {
public:
        virtual int g( C* c1, C* c2 ) { return ( 1 ); } //полное совпадение здесь
        virtual int g( C* c,  B* b )  { return ( 2 ); }
};
class Y : public C { //здесь ошибся, должно быть public : X
public:
        virtual int g( A* a, B* b ) { return ( 3 ); }
};
void OnStart()
{
        C* c = new C;
        Y* y = new Y;
        Print( y.g( c, c ));
}

Résultat : 3

Il s'avère que le C++ a un ordre "illogique" mais non ambigu, tandis que MQL a un ordre aléatoire - s'il y a une correspondance exacte des types, une classe de base est appelée dans un cas et une classe dérivée dans l'autre.