Au revoir le robot - bonjour le marasme - page 6

Nouveau commentaire
 
pansa:

Salut Vinin !

Vous avez vérifié l'indicateur: AltrTrend_Signal_v2_2.mq4

et a trouvé une erreur logique

dans la formule : SSP=MathCeil (Kperiod/iADX(NULL,0,PerADX,PRICE_CLOSE,MODE_MAIN,1))

vous avez souligné 1 à la fin

Que pensez-vous qu'il devrait être ?

pansa



Probablement 0 ! Essayez-le ! Et si vous êtes dans une boucle, essayez et i ou ce qui compte !
 
pansa:

Salut Vinin !

Vous avez vérifié l'indicateur: AltrTrend_Signal_v2_2.mq4

et a trouvé une erreur logique

dans la formule : SSP=MathCeil (Kperiod/iADX(NULL,0,PerADX,PRICE_CLOSE,MODE_MAIN,1))

vous avez souligné 1 à la fin

Que pensez-vous qu'il devrait être ?

pansa



Doitse déplacer
 
Andrei01:

L'éditeur génère les avertissements suivants sur cette construction standard, légale et populaire selon les normes du langage C : "declaration of 'a' hides global declaration at line 4" et "declaration of 'b' hides global declaration at line 4" qui est également incorrecte et illettrée par le noyau car il n'y a pas de déclaration d'une nouvelle variable à l'intérieur d'une fonction ni d'allusion à une éventuelle superposition de variables.

Par conséquent, même dans un code de programme pas très grand, nous avons des centaines d'avertissements non pertinents.

Les messages sont absolument corrects à 100%.

Il faut 5 à 10 ans de programmation active avec la pleine responsabilité de son code pour apprécier l'utilité d'un contrôle profond des compilateurs. Les langages C/C++ ont en grande partie acquis la réputation d'être un outil d'autodestruction en raison de la faiblesse des compilateurs qui ne voulaient et ne pouvaient pas analyser en profondeur la qualité et protéger les auteurs.

Même aujourd'hui, en 2014, les compilateurs C/C++ (ceux qui restent sur Windows après avoir été complètement détruits par Microsoft) n'ont pas pour mission de protéger les programmeurs contre eux-mêmes. Oui, il y a un faible (pratiquement inutile), pour un peu d'argent et séparément exécuter l'analyse de code dans Visial Studio, mais nous devons toujours utiliser séparément PVS Studio (Dieu merci pour ces gars-là), CPP Check et Lint pour la recherche profonde d'erreurs.

Test de cet exemple :

  • MQL4/MQL5 - donne des avertissements sur les erreurs potentielles
    declaration of 'a' hides global declaration at line 6   Test.mq4        13      14
declaration of 'b' hides global declaration at line 6   Test.mq4        13      22

  • Visual Studio 2012, y compris l'analyse du code - rien. La qualité de l'analyse pour les erreurs potentielles est nulle. Ils ne s'en soucient pas car il n'y a pas eu de concurrent depuis longtemps.

  • PVS Studio - rapports correctement.
    V669 The 'a', 'b' arguments are non-constant references. The analyzer is unable to determine the position at which this argument is being modified.
     It is possible that the function contains an error. test.cpp 17

  • Lint - rapporte la même chose, mais le 'x' se cache.


Notre tâche est de réaliser un compilateur de qualité qui soit bon dans le contrôle de la qualité et qui ne permette pas les techniques suicidaires/insensées des langages C/C++.

 
Renat:

Je pense aussi que les messages sont complètement inutiles. Je ne suis pas un programmeur professionnel, mais ce genre d'absurdité dans µl me stresse. Je me demande si si les références à a et b sont constantes, PVS Studio générera-t-il un avertissement (pas moyen de le vérifier moi-même) ?

int a=1,b=2;
//--------------------------------------------------------------------
void start(){        
        int k=sum(a,b);
        Alert(k);
}
//--------------------------------------------------------------------
int sum(const int& a, const int& b){        
        return(a+b);
}
 
Renat:

Test de cet exemple :

  • MQL4/MQL5 - donne des avertissements d'une erreur potentielle

1. Pourriez-vous donner un exemple de ce que pourrait être exactement l'erreur potentielle dans ce code simple, sur laquelle le compilateur émet un avertissement ?

Prendre soin des programmeurs est certainement une bonne chose, à condition que cela ait une explication logique raisonnable et ne devienne pas trop envahissant.

2. Je pense que la qualité du code écrit n'est pas liée à la qualité du compilateur et à sa capacité d'analyser la syntaxe, mais qu'elle ne se produit que lorsque l'environnement de test est suffisamment bien écrit pour vous permettre d'effectuer une analyse fonctionnelle approfondie du code écrit. Mais croire en une analyse syntaxique salvatrice du code sans coquille de test est une utopie et un gaspillage d'efforts.

C'est pourquoi les programmeurs professionnels ne regardent presque jamais les avertissements car les compilateurs, par définition, ne peuvent pas fournir une analyse fonctionnelle du code, alors que même un programmeur novice connaît de toute façon la syntaxe du langage.

 
Renat:

Les messages sont absolument corrects à 100%.

Ils sont corrects, mais ils ne sont pas pratiques. Il est également très important que ce comportement du compilateur ne puisse pas être contrôlé.

Renat:

Il faut 5 à 10 ans de programmation active avec la pleine responsabilité de son code pour que quelqu'un puisse apprécier l'utilité du contrôle profond pour les compilateurs. Les langages C/C++ ont en grande partie acquis la réputation d'être un outil d'autodestruction en raison de la faiblesse des compilateurs qui ne voulaient et ne pouvaient pas analyser en profondeur la qualité et protéger les auteurs.

Je me demande pourquoi exactement ces langages ont été pris comme base pour MQL4/MQL4++/MQL5 ?

Après tout, il ne s'agit pas de compilateurs en premier lieu, mais de la conception de ces langages.

Renat:

Même aujourd'hui, en 2014, les compilateurs C/C++ (ceux qui restent sur Windows après avoir été complètement détruits par Microsoft) n'ont pas pour mission de protéger les programmeurs contre eux-mêmes. Oui, il y a une analyse de code faible (pratiquement inutile), pour un certain prix et exécutée séparément dans Visial Studio, mais nous devons toujours utiliser séparément PVS Studio (Dieu soit loué pour ces gars-là), CPP Check et Lint pour trouver des bogues profonds.

Test de cet exemple :

  • MQL4/MQL5 - donne des avertissements sur les erreurs potentielles

  • Visual Studio 2012, y compris l'analyse du code - rien, la qualité de l'analyse pour les erreurs potentielles est nulle. Ils ne s'en soucient pas puisqu'il n'y a plus de concurrents depuis longtemps.

  • PVS Studio - rapports corrects

  • Lint - il génère la même chose, donc le 'x' cache...

Premièrement, Microsoft n'est pas omnipotent et omniprésent. Et deuxièmement, il reste d'autres compilateurs sur Windows. Je vais vous donner un exemple, bien que je le compile sous Linux, mais les versions Windows et Linux de ce compilateur ne diffèrent pas dans la partie "recherche profonde des erreurs". Le code source est légèrement modifié :

int a=1,b=2;
//--------------------------------------------------------------------
int sum(int& a, int& b){        
        return(a+b);
}
//--------------------------------------------------------------------
int main(){        
        return sum(a,b);
}

Compilation et messages du compilateur :

$ icpc -c -Wremarks 1.cpp
1.cpp(3): remark #1418: external function definition with no prior declaration
  int sum(int& a, int& b){        
      ^

1.cpp(3): remark #3280: declaration hides variable "a" (declared at line 1)
  int sum(int& a, int& b){        
               ^

1.cpp(3): remark #3280: declaration hides variable "b" (declared at line 1)
  int sum(int& a, int& b){        
                       ^

Vous voyez, en 2014, il y a des compilateurs pour Windows qui ont ce même service de "recherche profonde d'erreurs".

Notez que le droit de décider d'utiliser ou non le "deep lookup" est donné au programmeur : le même code dans une compilation plus pratique sans l'option "-Wremarks" mais avec tous les avertissements activés avec l'option "-Wall" compile sans aucun commentaire :

$ icpc -c -Wall 1.cpp
$

En outre, ce compilateur permet de contrôler la "recherche approfondie" au niveau des remarques individuelles, en désactivant celles que le programmeur considère comme inutiles.

La version suivante du compilateur est utilisée :

$ icpc --version
icpc (ICC) 15.0.0 20140723
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

À propos, ce compilateur s'intègre à Visual Studio, du moins les versions antérieures de ce compilateur s'intégraient aux versions antérieures de Visual Studio.

Renat:

Notre tâche est de réaliser un compilateur de qualité qui soit bon dans le contrôle de la qualité et qui ne permette pas les techniques suicidaires/insensées des langages C/C++.

Un compilateur de qualité doit avant tout "fonctionner", c'est-à-dire qu'il doit correspondre à la définition du langage, sinon toutes ses autres performances perdront absolument leur sens :

#property strict

/******************************************************************************/
class A {
private:
  /******************************************************************************/
  A() { }

  /******************************************************************************/
  void f() { }

public:
  /******************************************************************************/
  static void sf1(A &a) {
    a.f(); // Нет ошибки
  }

  /******************************************************************************/
  static void sf2() {
    A a; // Место "ошибки"

    a.f(); // Нет ошибки
  }
};

/******************************************************************************/
void OnStart() {
}

Pourquoi la méthode f() déclarée dans la section privée est-elle parfaitement appelée depuis une méthode statique comme il se doit, mais le constructeur de la classe, également déclaré dans la section privée, n'est "pas appelé" depuis la même méthode statique lors de la définition d'une variable ?

Messages d'erreur :

'A::A' - cannot call private member function

Ce bug du compilateur ne permet pas, par exemple, d'implémenter le singleton de Myers de manière humaine (cet exemple n'est PAS une implémentation dudit singleton). Et ce n'est pas le dernier bug en matière d'accès aux entités déclarées dans la section privée.

Il s'agit exactement d'un bug, et non d'une fonctionnalité dirigée, par exemple, contre les techniques suicidaires/déraisonnables, car une fois que vous remplacez la définition automatique des variables par la création dynamique d'objets, le constructeur est soudainement appelé de la manière la plus merveilleuse qui soit :

  /******************************************************************************/
  static void sf2() {
    A *a = new A;

    a.f();
    delete a;
  }

Ce code compile déjà sans erreurs. De plus, vous pouvez vous assurer que le constructeur est déjà appelé dans ce cas en insérant une impression d'un message du code du constructeur.

Tant que de tels bogues subsistent, il est étrange de parler d'un compilateur de qualité. Lorsqu'il s'agit d'erreurs dans l'implémentation du langage lui-même, les compilateurs C/C++, qu'ils soient commerciaux ou non, sont de loin supérieurs aux compilateurs MQL4++ car ils ne contiennent pas de telles absurdités. Tellement mieux que je dirais que, comparé à eux, le compilateur MQL4++ ne "fonctionne" pas du tout.

La seule caractéristique vraiment forte du compilateur MQL4++ qui permet un contrôle sérieux de la qualité du code à ce stade est l'émission d'avertissements au cas où le programmeur ne contrôlerait pas les valeurs de retour des fonctions qui peuvent échouer, par exemple les fonctions de trading. Cependant, même une caractéristique aussi forte du compilateur n'a qu'une valeur très limitée lorsque la qualité de sa mise en œuvre est si faible.

 
Pavlick:

Je pense aussi que les messages sont complètement inutiles. Je ne suis pas un programmeur professionnel, mais ce genre d'absurdité dans µl me stresse. Je me demande si si les références à a et b sont constantes, PVS Studio générera-t-il un avertissement (pas moyen de le vérifier moi-même) ?

int a=1,b=2;
//--------------------------------------------------------------------
void start(){        
        int k=sum(a,b);
        Alert(k);
}
//--------------------------------------------------------------------
int sum(const int& a, const int& b){        
        return(a+b);
}
Le compilateur Intel C++ 15.0.0 produit les mêmes remarques dans les deux cas lorsqu'il compile avec l'option -Wremarks.
 
simpleton:

Ils sont fidèles, mais pas pratiques.

Eh bien, si les indications d'erreurs potentielles sont correctes, il est nécessaire de corriger ces erreurs.
 
Renat:
Eh bien, si les pointeurs vers des erreurs potentielles sont corrects, alors ces erreurs doivent être corrigées.

Une erreur potentielle n'est que cela, une erreur potentielle n'est pas nécessairement une erreur. Par conséquent, l'affirmation selon laquelle "cela signifie que nous devons corriger ces erreurs" est incorrecte, car il se peut que ce ne soit PAS du tout des erreurs.

Il existe des cas où une erreur est presque certainement présente, par exemple lorsque le résultat d'un appel de fonction n'est pas vérifié, ce qui peut entraîner un échec. Un avertissement sur un tel cas est à la fois approprié et très utile. Les avertissements concernant les cas où vous ne pouvez pas savoir avec certitude s'il y a une erreur ou non sont généralement à la fois non pertinents et inutiles. Lorsque les noms ne sont pas divulgués, vous ne pouvez pas dire qu'il y a presque certainement une erreur.

Oui, il est possible pour un programmeur d'obtenir toutes sortes de diagnostics sur la base d'une "recherche approfondie" afin de déterminer s'il existe des erreurs potentielles, c'est-à-dire des erreurs commises par inadvertance. Mais cela ne devrait pas être le mode principal du compilateur et il devrait être possible de le désactiver. Afin de protéger les novices d'éventuelles erreurs de ce type, les diagnostics peuvent être activés par défaut, c'est-à-dire après l'installation. Cependant, vous devriez toujours pouvoir le désactiver.

Il est évident que les faits de cacher un nom dans une portée fermée qui a été précédemment déclaré dans la portée extérieure sont détectés par le compilateur Intel comme de simples remarques et non comme des avertissements pour la même raison : il pourrait ne PAS s'agir du tout d'erreurs. Et dans d'autres compilateurs, y compris les compilateurs non commerciaux, de tels faits cachés ne correspondent PAS à un quelconque avertissement. Parce que toute l'expérience collective des utilisateurs de compilateurs, c'est-à-dire des programmeurs, nous dit que cela ne devrait PAS être un avertissement. Et, bien sûr, l'utilisateur doit pouvoir configurer les avertissements/marques qui seront émis et ceux qui ne le seront pas.

D'ailleurs, puisque MQL est un langage distinct qui ne doit pas suivre les normes C/C++, ne serait-il pas plus simple de désactiver le masquage des noms dans les scopes fermés ?

  
1.cpp(3): remark #3280: declaration hides variable "a" (declared at line 1)
  int sum(int& a, int& b){       

Cette remarque est dénuée de sens et ne donne en principe aucune information utile au programmeur, car il n'y a pas de dissimulation de la variable "a" au départ, comme indiqué.

Le masquage ne se produit que lorsqu'une copie locale de la variable est créée, ce qui est également une action légitime. Même si une erreur se produit soudainement dans le code à cause de cette dissimulation, elle peut être facilement retrouvée précisément parce que la recherche trouve immédiatement le même nom. Si nous commençons à changer et à modifier les noms dans un modèle de fonction, qui est une "solution" à cette règle par la logique du compilateur, la situation de recherche d'erreurs deviendra beaucoup plus compliquée et la confusion sera grande dans la compréhension du code. Cela semble évident.

12345678910111213...16
Nouveau commentaire
Raison: