Erreurs, bugs, questions - page 2415

Nouveau commentaire
 
Stanislav Korotky:

C'est une sorte de restriction draconienne. Quelle est la raison d'être de ce système à l'heure actuelle ? Et comment est-il pratique de spécifier des grappes d'un tas de caractères ? Pour multiplier une douzaine de paramètres différents ? C'est pratique ?

La justification se trouve dans le protocole d'échange avec l'agent de contrôle.

Pour définir un groupe de caractères, écrivez ce groupe dans un fichier texte et passez-le en utilisant #property tester_file.

 

Mais avec un seul test, il est également transmis à l'agent de test et fonctionne sans restriction.

Pourquoi y a-t-il une limitation pour les entrées statiques aussi, elles peuvent ne pas être transmises à l'agent du tout.

S'il ne s'agit même pas d'un bogue, prenez-le comme une demande d'amélioration.

 
Alexey Navoykov:

Bug du compilateur. Il génère une erreur d'ambiguïté, bien que tout soit sans ambiguïté ici. Lapremière méthode devrait être appelée comme la plus appropriée. Testé en C++.

Comment la méthode la mieux adaptée est-elle définie ?

 
Slava:

La justification se trouve dans le protocole d'échange avec l'agent de contrôle.

Pour spécifier un groupe de caractères, écrivez ce groupe dans un fichier texte et passez-le en utilisant la propriété #tester_file.

Comment cela s'intègre-t-il dans les produits destinés aux utilisateurs finaux ? Cette limite a peut-être été justifiée auparavant, mais j'en doute, compte tenu des autres quantités de données transmises. L'augmentation de la limite ne comporte pas la menace d'une incompatibilité.

 
fxsaber:

Comment détermine-t-on qu'il est approprié ?

Si nous parlons de la norme C++, alors :

13.3 Résolution des surcharges. La résolution de surcharge est un mécanisme permettant de sélectionner la meilleure fonction à appeler, compte tenu d'une liste d'expressions qui doivent être les arguments de l'appel et d'un ensemble de fonctions candidates qui peuvent être appelées en fonction du contexte de l'appel. Les critères de sélection de la meilleure fonction sont le nombre d'arguments, la façon dont les arguments correspondent à la liste des types de paramètres de la fonction candidate, la façon dont (pour les fonctions membres non statiques) l'objet correspond au paramètre implicite de l'objet, et certaines autres propriétés de la fonction candidate. [ Note : La fonction sélectionnée par la résolution de surcharge n'est pas garantie d'être appropriée pour le contexte. D'autres restrictions, telles que l'accessibilité de la fonction, peuvent rendre son utilisation dans le contexte d'appel mal formulée.

En d'autres termes, cela devrait fonctionner comme suit :

class A { };

class B
{
  A _a[];
 public:
        A * operator[](uint i)       { return &_a[i]; }
  const A * operator[](uint i) const { return &_a[i]; }  
};

void OnStart()
{
  B b1;
  const B b2;
  b1[0]; // []
  b2[0]; // [] const
}
 
Andrey Pogoreltsev:

Si nous parlons de la norme C++, alors :

13.3 Résolution des surcharges. La résolution de surcharge est un mécanisme permettant de sélectionner la meilleure fonction à appeler, compte tenu d'une liste d'expressions qui doivent être les arguments de l'appel et d'un ensemble de fonctions candidates qui peuvent être appelées en fonction du contexte de l'appel. Les critères de sélection de la meilleure fonction sont le nombre d'arguments, la façon dont les arguments correspondent à la liste des types de paramètres de la fonction candidate, la façon dont (pour les fonctions membres non statiques) l'objet correspond au paramètre implicite de l'objet, et certaines autres propriétés de la fonction candidate. [ Note : La fonction sélectionnée par la résolution de surcharge n'est pas garantie d'être appropriée pour le contexte. D'autres restrictions, telles que l'accessibilité de la fonction, peuvent rendre son utilisation dans le contexte d'appel mal formulée.

En d'autres termes, cela devrait fonctionner comme suit :

Pour b2, absence totale d'ambiguïté. b1 ne l'est pas.

 
fxsaber:

Comment déterminer celui qui est approprié ?

Dans cet exemple, une méthode d'objet non constante est demandée, donc, toutes choses égales par ailleurs, elle doit être appelée.

Si on enlève le casting et qu'on fait un argument de type int pour les deux méthodes, le code se compile normalement. Donc, le problème dans MQL concerne le casting. Ce casting ne doit pas affecter le code car il est identique.

 
fxsaber:

Pour b2, il n'y a aucune ambiguïté. b1 ne l'est pas.

Il n'y a pas besoin d'ambiguïté ici. Il s'agit simplement de l'ordre dans lequel les méthodes surchargées sont appliquées. C'est-à-dire que la tâche de résoudre la surcharge n'est pas de créer un dilemme, mais de choisir la méthode la mieux adaptée. En mettant de côté le modificateur d'accès, c'est la première méthode du tableau ou cela dépend de l'implémentation du compilateur, mais il n'y a aucune ambiguïté.

Mais s'il y avait 2 méthodes, avec des paramètres d'entrée différents par exemple :

class B
{
  A _a[];
 public:
        A * operator[](int i)  {...}
        A * operator[](bool i) {...}  
};
B b;
b[0];    // ok
b[true]; // ok
b[0 u];   // ambiguous call to overloaded function

En revenant au C++, le même vecteur en a un :

reference       operator[]( size_type pos );
const_reference operator[]( size_type pos ) const;

C'est donc une situation parfaitement normale.

 
Stanislav Korotky:

Comment cela s'intègre-t-il dans les produits destinés aux utilisateurs finaux ? Cette limite a peut-être été justifiée auparavant, mais j'en doute, compte tenu des autres quantités de données transmises. L'augmentation de la limite ne comporte pas la menace d'une incompatibilité.

Pour commencer, dans le cache d'optimisation, les paramètres des chaînes de caractères ont toujours été tronqués à 63 caractères, tant dans MT5 que dans MT4.

Lors de l'envoi d'événements, la chaîne ne peut pas non plus dépasser 63 caractères.

C'est-à-dire que ce qui vient de l'extérieur est limité

Quant aux produits destinés aux utilisateurs finaux. Le vendeur doit tenir compte de ces limites. Et s'il ne les connaît pas, c'est qu'il n'a pas suffisamment testé son produit avant de le vendre.

 
Andrey Pogoreltsev:

Il n'y a pas besoin d'ambiguïté ici. Il s'agit simplement de l'ordre dans lequel les méthodes surchargées sont appliquées. C'est-à-dire que la tâche de la solution de surcharge n'est pas de créer un dilemme, mais de choisir la méthode la mieux adaptée. Si nous ignorons le modificateur d'accès, la première méthode du tableau est prise ou cela dépend de l'implémentation du compilateur, mais il n'y a pas d'ambiguïté.

Voici ce qui se passe s'il y a 2 méthodes avec des paramètres d'entrée différents par exemple :

En revenant au C++, le même vecteur en a un :

C'est donc une situation tout à fait normale.

Vous avez donné un exemple très simple, celui des écoles primaires. Il semble que cela n'ait rien à voir avec l'exemple original.


Alexey Navoykov:

Dans cet exemple, il s'agit d'une méthode d'un objet non constant, qui doit donc être appelée, toutes choses égales par ailleurs.

Je n'étais pas au courant de cette règle, merci.

Si on enlève le casting et que l'argument est de type int pour les deux méthodes, le code compile normalement. C'est donc le casting qui cause le blocage de MQL. Ce casting ne doit pas affecter le code puisqu'il est identique.

Il semble que la cause du problème soit que le compilateur ne vérifie pas si le casting des méthodes surchargées est identique.

1...240824092410241124122413241424152416241724182419242024212422...3184
Nouveau commentaire