Erreurs, bugs, questions - page 2564

Nouveau commentaire
 
Andrey Barinov:

Toutes les mêmes règles s'appliquent aux statiques (private, protected, public), elles ne nécessitent simplement pas la création d'un objet.

Pas en général : par exemple, une statik publique ne peut pas être restreinte dans une classe dérivée

 
Andrey Barinov:



hmmm... Comment expliquer l'absurdité de la situation... Je vous ai suggéré de lire les posts des admins (développeurs), je vous ai montré l'aide qu'ils ont écrite, que voulez-vous de moi avec vos photos ?

Je ne me demande pas pourquoi il en est ainsi, je lis le forum et l'aide, et je fais ce qui est recommandé par les développeurs. Si vous pensez que c'est nécessaire, écrivez à "committee on protection of C++ standards", à UN... Eh bien, au moins l'administrateur dans le PM, si faible, mais alors verrouiller les messages des développeurs et obtenir votre chemin !

ZSY : J'ai réussi à insérer le code source et non les images, pourquoi le vôtre ne l'a-t-il pas fait ?

int print(int value)
{  Print(value,":",__FUNCTION__); 
 return(value);
}
class A
{
private:
   static int        a1;
   static void       inc_a1(){a1++; Print("a1 = ", a1);}
protected:
   static int        a2;
public:
   static int        a3;

};
//+------------------------------------------------------------------+
static int A::a1 = print(1);
static int A::a2 = print(2);
static int A::a3 = print(3);

//+------------------------------------------------------------------+
void OnStart()
{

A::inc_a1();
A::inc_a1();
A::inc_a1();

}

2019.09.17 22:11:49.534 tst (EURUSD,H1) 1:print

2019.09.17 22:11:49.535 tst (EURUSD,H1) 2:print

2019.09.17 22:11:49.535 tst (EURUSD,H1) 3:print

2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 2

2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 3

2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 4

ZS : la situation est assez comique, je voulais aider, maintenant je fais des excuses.... Pourquoi ? - Eh bien, frappez la rampe pour la vérité... marchez sur le râteau....
 
Igor Makanu:

Le seul bogue dans le code est dans l'accès à la méthode privée. Ce bug est apparu récemment.

 

La fonction ChartOpen renvoie toujours 0 dans le service. Bien que le tableau lui-même s'ouvre.

#property service

//int OnInit()
void OnStart()
  {
   long Otvet= ChartOpen(Symbol(),PERIOD_D1);
   Print("Otvet=",Otvet);

  // return(INIT_SUCCEEDED);
  }
 
fxsaber:

Le seul bogue dans le code est dans l'accès à la méthode privée. Ce bug est apparu récemment.

Je pensais avoir oublié quelque chose, alors j'ai relu comment les statiques se comportent en C#https://metanit.com/sharp/tutorial/3.6.php.

Les membres statiques d'une classe sont communs à tous les objets de la classe, vous devez donc les désigner par leur nom de classe :

Notez que les méthodes statiques ne peuvent faire référence qu'à des membres statiques de la classe. On ne peut pas adresser des méthodes non statiques, des champs, des propriétés à l'intérieur d'une méthode statique.


En MQL, les statiques sont initialisées avant d'exécuter OnInit(), discutons maintenant de la visibilité globale des méthodes privées pour les statiques..... ce comportement des statiques en MQL - si vous utilisez les statiques, cela signifie que nous n'utilisons pas les fonctions de protection des données d'une classe, à mon avis.

Quelle est la taille de cet insecte ? - la façon dont les développeurs le feront, j'ai dit que le comportement dans les opérations de contexte est déterminé par le programmeur (l'opérateur de résolution de contexte est l'opérateur avec la plus haute priorité dans le langage ! ), et le compilateur aidera correctement - enfin, comme il se doit)))

Est-ce que ça marche comme ça ?

class A
  {
private:
   static void              My_function()
     {
      Print("^_^");
     }
  };
  
A a;
void OnStart()
  {
   A::My_function();
   a.My_function();  // 'A::My_function' - cannot access private member function        
  }

dans l'ensemble, il fait le travail


PS : mis à jour en 2145 - le code avec les statiques se comporte de la même manière, si cela reste comme ça pendant six mois, il s'avérera que c'est le comportement prévu des statiques ;)

UPD : rappelez-vous, comme l'argot pour tout cela est appelé - dirty tricks ! ))) - Recherchez de nombreux exemples sur le web, où ce comportement est accepté comme une norme de langage, et où il est lié à un compilateur spécifique du fabricant. En Python, eval() ne casse-t-il pas effectivement l'exécution linéaire du code ? - Eh bien, certains le font et d'autres non, car le comportement est imprévisible.


UPD : vérifier sur 2145 ma question d'il y a un moishttps://www.mql5.com/ru/forum/320733#comment_12989063

https://www.mql5.com/ru/forum/320733#comment_12958594

void OnStart()
  {
   double x=100.0;
   f(x);
  }
//_______________________________________________________________________
void f(bool v)
  {
  }
//_______________________________________________________________________

rien n'a changé, sur une vérification du type bool le compilateur n'a pas appris à écrire des avertissements - c'est très désagréable, je cherchais une erreur dans mon code, bien que je sois sûr que le compilateur MQL vérifie toujours la correspondance des types

 
Igor Makanu:

A quel point est-ce un bug ? - Peu importe comment les développeurs le transforment, c'est comme ça que ça va être.

Il est évident que le bug sera corrigé.

Rien n'a changé, le compilateur n'a pas appris à écrire des avertissements sur bool lors de la vérification des types.

La conversion automatique des pointeurs et des types numériques en bool est très pratique.

 
Igor Makanu:

rien n'a changé, sur bool lors de la vérification des types le compilateur n'a pas appris à écrire des avertissements - c'est très désagréable, je cherchais déjà une erreur dans mon code, bien que j'étais sûr que le compilateur MQL surveille toujours strictement la correspondance des types

Il n'y a pas de perte de données pendant cette coulée. Soit 0, soit pas 0.

Un autre cas est celui où double -> tout type d'entier (jusqu'à et y compris int32)

 
Slava:

Avec ce moulage, il n'y a pas de perte de données. Soit 0, soit pas 0.

Une autre chose est que lors du casting double -> tout type d'entier (jusqu'à et y compris int32)

mais dans l'autre sens ?

Je cherchais un bug dans mon code

Au début, j'ai écrit un test, mais j'ai d'abord utilisé int, puis j'ai renoncé à utiliser bool, mais je n'ai pas corrigé tout le code, je ne me souviens pas, mais c'était comme ça :

void OnStart()
{  int x=100.0;
   f(x); }
//_______________________________________________________________________
void f(int  v)  //так тестил
{
   if(v>0) v++;

}

//_______________________________________________________________________
void f(bool  v)  // потом решил, что мне нужен флаг, а ниже забыл исправить код
{
   if(v>0) v++;

}
//_______________________________________________________________________


Je suis en quelque sorte prêt pour un tel comportement maintenant, mais pourquoi est-ce que j'écris à ce sujet...bien, en vérifiant les conditions MQL dans if() - est-ce qu'il contrôle strictement les types ? toute utilisation d'opérations non booléennes émettra un avertissement ? - Et de la même manière que j'ai écrit en C# dans VS2017 - mon code d'exemple ne compile pas et MQL ne lance pas d'avertissement. A mon avis, pour ceux qui sont nouveaux dans la programmation en MQL, un tel comportement implique quelques surprises.

 
fxsaber:

Il est évident que le bug sera corrigé.

Je ne vais pas discuter, mais mon opinion est que vous ne devriez pas compter sur le contrôle du compilateur lorsque vous quittez la classe via les statiques ainsi que l'utilisation de l'opérateur de résolution de contexte,

Par exemple, si vous écrivez une méthode/un champ statique ou si vous utilisez :: : - ne comptez pas sur le compilateur.

 
Igor Makanu:

Je ne vais pas discuter

J'ai décidé de décrire le problème dont nous discutons. D'ailleurs, le comportement de MQL est devenu de plus en plus similaire à celui de C#, le code ne compile pas

//+------------------------------------------------------------------+
class A
{
private:
   int               count;
public:
                     A():count(0) {}
   static void       inc()        { count++; }

};

A a;
//+------------------------------------------------------------------+
void OnStart()
{
   a.inc(); //code generation error 
   A::inc();
   
}
//_______________________________________________________________________

J'ai implémenté la méthode Inc() - elle fonctionne avec les champs protégés.

si j'ai ajouté un modificateur statique - où le compilateur doit-il arrêter de vérifier - j'ai décidé que j'avais besoin d'un point d'entrée vers un objet hors de la portée ?

1...255725582559256025612562256325642565256625672568256925702571...3184
Nouveau commentaire