Erreurs, bugs, questions - page 2755

[Mesaoria]

J'ai un conseiller expert très simple (voir la capture d'écran).

Des objets graphiques sont superposés au graphique.

Avant la mise à jour du terminal d'hier, les niveaux de négociation étaient indiqués sur les graphiques, mais ils ont maintenant disparu.

J'ai créé des graphiques comme indiqué dans l'exemple du manuel. Je n'ai pas trouvé de propriétés graphiques permettant d'afficher les niveaux de transaction (seuls les graphiques de base possèdent une telle propriété).

Aidez-moi, s'il vous plaît.

Captures d'écran de la plateforme MetaTrader

GBPUSD, M5, 2020.05.25

Forex Club International Limited, MetaTrader 5, Real

[Ivan_Invanov]

Salut. Veuillez m'aider à comprendre ce qui est écrit.

mqlrate rt [2] ;

Ai-je raison de supposer qu'il s'agit d'un tableau de deux structures qui ont automatiquement reçu les mêmes données de structure ?

Plus loin, il n'y a pas d'affectation de données au tableau, puis les données du tableau sont utilisées en une seule fois.

[Vladimir Karputov]

Ivan_Invanov:

Salut. Veuillez m'aider à comprendre ce qui est écrit.

mqlrate rt [2] ;

Ai-je raison de supposer qu'il s'agit d'un tableau de deux structures qui ont automatiquement reçu les mêmes données ?

Écrit en MQL5 :

MqlRates rt[2]

signifie : un tableau statique de deux structuresMqlRates est déclaré. Après la déclaration, ces structures peuvent stocker du charabia, elles doivent donc être explicitement remplies de données.

[Ivan_Invanov]

Vladimir Karputov:

Écriture en MQL5 :

signifie : un tableau statique de deux structuresMqlRates est déclaré. Une fois déclarées, ces structures peuvent stocker du charabia, donc ces structures doivent être explicitement remplies de données.

Merci.

[Sergey Dzyublik]

Alexey Navoykov:

Erreur de compilation. Fonctionne bien dans les anciennes versions.

Oui, cela existe, signalé dès 2020.03.25, déjà jour après jour depuis 2 mois...
(non corrigé par MT5(build 2390)) (nouveau) Erreur de compilation, lors de l'utilisation du modificateur d'accès par défaut lors de l'héritage dans une classe modèle, lorsque le paramètre modèle agit comme classe de base.

[Alexey Navoykov]

Un autre bug :

class A
{
  void operator=(A const&) = delete;
};

class B : public A
{
};

class C : public B
{
};

class D : public C
{
 public:
  void operator=(A const& other) { }
};

void OnStart()
{
  C c;
  D d;
  d = c; // attempting to reference deleted function 'void C::operator=(const C&)'
}

C::operator=, bien que D::operator= soit exécuté ici. Pour contourner ce bogue, vous devez surcharger l'opérateur pour toutes les classes de base de la hiérarchie.

p.s. En général, les développeurs ont promis de corriger le comportement incorrect de l'opérateur d'assignation il y a longtemps, mais il est toujours là. C'est un scandale. Par exemple, le code suivant compile sans erreur bien qu'il assigne quelque chose :

#include <Expert\Expert.mqh>

#include <Strings\String.mqh>

void OnStart()
{
  CExpert Expert;
  CString String;
  Expert = String; // Ошибки нет. Типа всё нормально?
}

[Sergey Dzyublik]

Alexey Navoykov:

Un autre bogue :
1) Il se plaint de C::operator=, bien que D::operator= soit exécuté ici. Pour éviter ce bug, nous devons surcharger l'opérateur pour toutes les classes de base de la hiérarchie.
2) En général, les développeurs ont promis de corriger le comportement incorrect de l'opérateur d'assignation il y a longtemps mais il est toujours là - c'est un scandale. Par exemple, le code suivant compile sans erreur bien qu'il assigne ce qu'il est :

1) Il ne s'agit probablement pas d'un bug mais plutôt d'un comportement naturel compte tenu des spécificités de MQL, à savoir :
En MQL, les méthodes et les champs de la classe de base sont "directement disponibles" à partir des classes dérivées.
En substance, le comportement d'héritage dans MQL est similaire à l'utilisation de la déclaration pour chaque champ et méthode de base en C++.
C++ en ligne: https://onlinegdb.com/rJkckvFsU

class A
{
public:
  void operator=(A const&) = delete;
};

class B : public A
{
};

class C : public B
{
public:
    //void operator=(C const& other) { printf("C");}
};

class D : public C
{
public:
#ifdef __cplusplus
  using A::operator=;
  using B::operator=;
  using C::operator=;
#endif
  void operator=(A const& other) { printf("D");}
};

void OnStart()
{
  C c;
  D d;
  d = c; 
}

Ainsi, toutes les fonctions operator= des classes de base sont également impliquées dans l'opérationd = c ;
lors de la recherche de la fonction appropriée.
Par conséquent, la signature optimale pour un appel de fonction surchargée est la signature par défaut et supprimée void operator=(const C&).

[Alexey Navoykov]

Sergey Dzyublik:

1) Très probablement, ce n'est pas un bug, mais un comportement naturel compte tenu des particularités de MQL, à savoir :
En MQL, les méthodes et les champs d'une classe de base sont "directement disponibles" à partir des classes descendantes.
En substance, le comportement d'héritage dans MQL est similaire à l'utilisation de la déclaration pour chaque champ et méthode de base en C++.
C++ en ligne: https://onlinegdb.com/rJkckvFsU

Ainsi, l'opérationd = c ;
fait également intervenir toutes les fonctions operator= des classes de base lors de la recherche de la fonction appropriée.
Par conséquent, la signature optimale pour un appel de fonction surchargée est la signature par défaut et distante void operator=(const C&).

Il ne faut pas chercher un sens sacré dans un défaut évident de la langue. J'ai déjà soulevé ce problème ici et Ilyas a assuré qu'il sera corrigé. Mais presque 10 mois se sont déjà écoulés. (

En substance, le comportement de l'héritage dans MQL est similaire à celui du C++ qui utilise la déclaration

Ouais, eh bien, si en MQL par exemple 2 x 2 = 5, vous pourriez dire que c'est la même chose qu'en C++ en ajoutant une opération d'incrémentation au résultat)

[Sergey Dzyublik]

Alexey Navoykov:

Il n'est pas nécessaire de chercher un sens sacré dans un défaut évident de la langue.

On vous a expliqué comment et pourquoi cela fonctionne, si c'est difficile pour vous - heureusement je ne peux pas vous aider...
Il ne s'agit pas d'une signification sacrée, mais d'une approche commune afin d'abaisser le niveau d'entrée de l'utilisateur, de sorte qu'il puisse accéder aux champs et aux méthodes de la classe de base sans utiliser "this.", et également en cas de surcharge d'une fonction de la classe de base.

[Alexey Navoykov]

Sergey Dzyublik:

On vous a expliqué comment et pourquoi cela fonctionne, si c'est compliqué pour vous - heureusement, je ne peux pas vous aider...
Il ne s'agit pas d'une signification sacrée, mais d'une approche commune afin d'abaisser le niveau d'entrée de l'utilisateur, de sorte qu'il puisse accéder aux champs et aux méthodes de la classe de base sans utiliser "this.", et également en cas de surcharge d'une fonction de la classe de base.

Dites-moi, vous n'avez rien d'autre à faire ? Dans le post précédent, vous avez créé un post vain pour prouver quelque chose d'incompréhensible et d'incompréhensible... Si vous pensez que les règles du C++ ont été inventées par des idiots et que vous êtes le plus intelligent ici, c'est votre choix. J'ai déjà démontré visuellement un certain nombre de problèmes que le comportement d'un tel opérateur incorrect cause. Et les développeurs eux-mêmes ont admis la faille.