Erreurs, bugs, questions - page 1118

Nouveau commentaire
 
micle:
au contraire... l'ancien, s'il n'affichait pas la plaque, pourquoi commencerait-il à l'afficher... c'est bizarre...
Je ne sais pas, mais le nouveau s'est comporté comme d'habitude sans aucune tablette et a commencé à télécharger les fichiers d'installation.
 
Zeleniy:
Je ne sais pas, mais le nouveau s'est comporté comme d'habitude sans aucun signe et a commencé à télécharger les fichiers d'installation.
mystique...
 
Zeleniy:
Je ne sais pas, mais le nouveau s'est comporté comme d'habitude sans aucun onglet et a commencé à télécharger les fichiers d'installation.

J'ai déjà vu que l'apparition d'une telle fenêtre pendant le processus d'installation pouvait être liée à la protection de l'ordinateur (apparemment, en raison d'une mise à jour régulière) et à la manifestation étrange qui s'ensuit.

Peu importe qu'il s'agisse d'un fichier d'installation précédent ou simplement téléchargé.

Maintenant je vais prendre note, pour l'avenir, juste au cas où, cette nouvelle dépendance pour moi (je n'expérimente pas maintenant).

Mais je suis heureux que votre problème soit résolu.

Une suggestion : si je me souviens bien, il y a eu une mise à jour du terminal MT5 récemment. Dans ce cas, il existe peut-être un lien entre l'invite du proxy, une version obsolète du fichier d'installation et le processus d'installation en ligne.
 

Extrait de la liste des modifications apportées à la nouvelle build MT5 de 2014.04.04 10:14 :"3. Terminal : Correction d' un bogue à cause duquel les objets graphiques n'étaient pas dessinés sur le graphique dans certaines conditions. "Je ne sais pas si les développeurs ont satisfait ma demande dans le SD #966979 ou s'il s'agit d'un autre type de correction, ou même d'un effet secondaire d'une amélioration dans la prochaine version, mais dans tous les cas, cela me convient maintenant. La liste des modifications indique qu'il s'agit d'un bogue, mais dans ma correspondance avec le SD, on m'a répondu sans équivoque :"Ce n'est pas un bogue, c'est une limitation pour économiser les ressources."

Vous pouvez maintenant regarder confortablement les constructions TA sur n'importe quel TF comme avant.

Merci, je ferme la demande.

 

La constance des méthodes peut être surchargée dans une classe dérivée (build 917)

class A {
public:
        virtual void f() const {}
        int x;
};
class B : public A {
public:
        virtual void f() /*не const*/ { x = 2; }
};
void g( const A* a ) { a.f(); }
void OnStart()
{
        A *a = new B();
        a.x = 1;
	Print( a.x ); //результат = 1
        g( a );
        Print( a.x ); //результат = 2, а обещали, что g( const A* ) не может менять объект
        delete( a );
}

Un autre exemple

class A {
public:
        virtual void f() const { Print( "1" ); }
};
class B : public A {
public:
        virtual void f()       { Print( "2" ); }
};
void g( const A* a ) { a.f(); }
void OnStart()
{
        A *a = new B();
        g( a );
        delete( a );
}

Résultat= 2, mais en C++ résultat = 1

L'erreur ne réside pas dans le fait que dans une classe dérivée on ne peut pas déclarer une méthode avec le même nom que dans la classe de base (ce qui est permis), mais que le C++ les considère comme différentes et que MQL considère que B::f() surcharge A::f() const.

 

La fonction Print() sort les non-nombres du signal float comme des non-nombres, ce qui est illogique, car double sort les deux normalement.

Float doit soit : 1) supprimer le préfixe Q des numéros de non-signaux et alors les numéros de signaux et de non-signaux seront imprimés de manière identique, soit 2) sortir les numéros de signaux avec le préfixe S. Si je me trompe, veuillez me donner un exemple de signal float non numérique qui serait imprimé par la fonction Print() sans le préfixe Q.

Par exemple, je prends un signal double non numérique, je le convertis en flottant et j'envoie les deux via Print(). Dans le premier cas, il imprime SNAN, dans le second QNAN.

 

Au cours de l'exploration des différentes manières d'écrire des données dans le fichier à partir du testeur, voici une erreur (abrégée, car elle ne convenait pas) :

2014.04.08 01:47:30.531 2013.07.01 02:10:00   00: 0x000000013FD1F038
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013 FD1F04D 498 BCD            mov        rcx, r13
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013 FD1F04A 41 B001            mov        r8b, 0x1
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013 FD1F043 80 BD3804000000    cmp        byte [rbp+0x438], 0x0
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013 FD1F040 83 C202            add        edx, 0x2
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013 FD1F03D 418 BD4            mov        edx, r12d
2014.04.08 01:47:30.531 2013.07.01 02:10:00   
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013 FD1F03B EB03              jmp        0x13fd1f040
2014.04.08 01:47:30.531 2013.07.01 02:10:00      crash -->  000000013 FD1F038 8 B50FC            mov        edx, [rax-0x4]
2014.04.08 01:47:30.531 2013.07.01 02:10:00   
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013 FD1F033 4885 C0            test       rax, rax
[cut]
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013 FD1EE6E 55                push       rbp
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013 FD1EE67 4 C894018          mov        [rax+0x18], r8
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013 FD1EE63 48895808          mov        [rax+0x8], rbx
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013 FD1EE60 488 BC4            mov        rax, rsp
2014.04.08 01:47:30.531 2013.07.01 02:10:00   Access violation at 0x000000013FD1F038 read to 0x00000003FFFFFFFF

C'est-à-dire, bien sûr, je comprends que cette erreur est le résultat naturel de ma maladresse. Et dans tous les cas, il a été rapidement corrigé (le problème était dans une tentative de passer des données non string dans FileWrite via une troisième fonction, si nécessaire - je peux le décrire plus en détail). Mais l'erreur n'est pas très claire et un peu effrayante :) et le compilateur n'indique nulle part que c'est attendu. Peut-être devrions-nous au moins ajouter une sorte de déformation ou quelque chose comme ça...

 
Lone_Irbis:

Au cours de l'exploration des différentes manières d'écrire des données dans le fichier à partir du testeur, voici une erreur (abrégée, car elle ne convenait pas) :

C'est-à-dire que, bien sûr, je comprends que cette erreur est le résultat naturel de ma maladresse. Et dans tous les cas, il a été rapidement corrigé (le problème était dans une tentative de passer des données non string dans FileWrite via une troisième fonction, si nécessaire - je peux le décrire plus en détail). Mais l'erreur n'est pas très claire et un peu effrayante :) et le compilateur n'indique nulle part que c'est attendu. Peut-être que nous devrions au moins ajouter une sorte de déformation ou quelque chose comme ça...

Oui, veuillez la décrire plus en détail.

Intéressé par la construction, le système d'exploitation, le débit binaire, les paramètres du testeur. Veuillez joindre le code pour la reproduction.

Merci.

 

OK, je vais essayer. J'ai pu revenir au bon moment et le reproduire, mais je ne peux pas isoler le bug et le reproduire séparément...

Build : MetaTester 5 x64 build 910 (07 Mar 2014) https://dl.dropboxusercontent.com/u/61587787/bugreport/build.png

Bureau Win7 x64 https://dl.dropboxusercontent.com/u/61587787/bugreport/system.png

copié de la fenêtre du testeur : https://dl.dropboxusercontent.com/u/61587787/bugreport/log.txt

captures d'écran du testeur (enfin, on ne sait jamais):https://dl.dropboxusercontent.com/u/61587787/bugreport/tester1.png https://dl.dropboxusercontent.com/u/61587787/bugreport/tester2.png

paramètres du testeur (je ne sais pas si je sais ce que je veux dire): https://dl.dropboxusercontent.com/u/61587787/bugreport/config.png

Extraits de code :

   int idx = 133;
   WriteCSV("test.csv",idx);
   
class Core { 
public:  
   void     WriteCSV(string FileName, string s1, string s2, string s3, string s4, string s5, string s6);
};

void Core::WriteCSV(string FileName, string s1, string s2="", string s3="", string s4="", string s5="", string s6=""){
   int handle = FileOpen(FileName,FILE_CSV|FILE_WRITE|FILE_SHARE_WRITE|FILE_UNICODE|FILE_COMMON,"~");
   if(handle == INVALID_HANDLE) Print("error");
   else FileWrite(handle,s1,s2,s3,s4,s5,s6);
   FileClose(handle);
}

Si on le remplace parWriteCSV("test.csv",(string)idx) ; - l'erreur disparaît. Les autres variables qui ne sont pas des chaînes de caractères n'ont rien à faire ici. La valeur de idx ne semble pas faire de différence (il s'agit simplement du numéro de série de la nouvelle dans le tableau). Reproduit sur n'importe quelle nouvelle en essayant de sauvegarder le résultat. Parmi les avertissements, seule laconversion implicite de "nombre" en "chaîne de caractères" est affichée, mais là encore, il n'y a que dans ce cas qu'elle se transforme en plantage.

Je n'ai pas vraiment envie de poster le code complet et le .set ici, mais je peux l'envoyer quelque part.

 

Erreur de compilation : le compilateur pense que je passe un pointeur par référence

class A {
};

void f1( A*  a ) {}
void f2( int a ) {}

void OnStart()
{
        A* const a1 = new A();
        f1( a1 ); // ошибка компиляции: constant variable cannot be as reference
        const int a2 = 1;
        f2( a2 ); //все нормально
}

Si j'écris f1( A* const a ), tout se compile bien, mais je n'écris pas f2( const int a ) et dans le cas de f2( int a ) le compilateur s'en sort bien.


по сути
f1( A*  a ) отличается от f1( A* const  a )
тем же, чем
f2( int a ) отличается от f2( const int a )
alors il devrait y avoir une erreur dans f2( a2 ) aussi
1...111111121113111411151116111711181119112011211122112311241125...3184
Nouveau commentaire