Erreurs, bugs, questions - page 1919

 
Anton Ohmat:

Pouvez-vous me dire si mql5 peut commenter la sortie d'erreur pendant la compilation comme en php ?

GetLastError()? Si non, quel format souhaiteriez-vous voir ?
 
Alexey Kozitsyn:
GetLastError() ? Si non, quel format souhaitez-vous voir ?

Et bien en php il y a @variable = ....

et la sortie d'erreur est commentée - pratique pour les erreurs simples au moment de la compilation (par exemple pour les incohérences de type lors de la conversion en chaîne).

 
Anton Ohmat:

eh bien, en php il y a @variable = ....

et la sortie d'erreur est commentée - pratique pour les simples erreurs de compilation (par exemple pour les incohérences de type lors de la conversion en chaîne).

Dans mql, vous devez vérifier le code d'erreur explicitement (au moment de l'exécution), alors qu'au moment de la compilation, un avertissement apparaîtra avec une possible erreur de conversion de type.
 
Alexey Kozitsyn:
Dans mql, vous devez vérifier le code d'erreur explicitement (au moment de l'exécution), et au moment de la compilation, un avertissement apparaîtra, s'il y a une erreur possible dans la conversion de type.
Je veux donc désactiver partiellement la sortie d'erreur au moment de la compilation.
 
Anton Ohmat:
C'est ainsi que je veux désactiver partiellement la sortie d'erreur sélective au moment de la compilation.
Il n'est pas nécessaire de désactiver quoi que ce soit. Aucune erreur ne se produira si les types sont correctement mappés les uns aux autres.
 
Anton Ohmat:
Je veux donc désactiver partiellement la sortie d'erreur au moment de la compilation.
Pour éviter de voir les erreurs et les avertissements au moment de la compilation, il suffit de les corriger dans le code. Ne vous méprenez pas, vous voulez travailler avec de l'argent.
 

Ambiguïté

struct A {
        int f() { return B::i; } //error: 'i' - protected member access error
};
struct B : A {
protected: //(*) или например private:
        static int i;
};
int B::i;
En même temps, sans protégé: (*) - compile sans erreurs

Attendu : même comportement avec et sans protected: (*) string

Facultatif : C++ ne compile pas les deux cas.

 
A100:

Ambiguïté

Dans le même temps, sans la chaîne protégée: (*) - il compile sans erreurs

Attendu : Même comportement avec et sans protected: (*) string

Le "prédécesseur" n'a pas besoin de voir les champs protégés/privés.

Si vous voulez que B::f() soit défini dans A::f(), vous devrez inventer quelque chose dans ce cas.
 
A100:

Facultatif : C++ ne compile pas les deux cas.

Si vous ajoutez

struct B ;

au début du code, l'un des deux cas devrait compiler. peut-être le compilateur mql est-il si intelligent qu'il ajoute lui-même la déclaration forward manquante ?

 
fxsaber:

L'"ancêtre" voit les champs protégés/privés et ne devrait pas le faire.

Et les champs publics : faut-il/ne faut-il pas ?

Combinateur:

Si nous ajoutons

struct B ;

Aucun effet