Auf Wiedersehen, Roboter - Hallo, Marasmus - Seite 6

Neuer Kommentar
 
pansa:

Hallo Vinin!

Sie haben den Indikator überprüft: AltrTrend_Signal_v2_2.mq4

und fand einen logischen Fehler

in der Formel : SSP=MathCeil (Kperiod/iADX(NULL,0,PerADX,PRICE_CLOSE,MODE_MAIN,1))

Sie haben die 1 am Ende unterstrichen

was sollte es Ihrer Meinung nach sein?

pansa



Wahrscheinlich 0! Versuchen Sie es, und wenn Sie in einer Schleife sind, versuchen Sie es mit i oder was auch immer zählt!
 
pansa:

Hallo Vinin!

Sie haben den Indikator überprüft: AltrTrend_Signal_v2_2.mq4

und fand einen logischen Fehler

in der Formel : SSP=MathCeil (Kperiod/iADX(NULL,0,PerADX,PRICE_CLOSE,MODE_MAIN,1))

Sie haben die 1 am Ende unterstrichen

was sollte es Ihrer Meinung nach sein?

pansa



Mussschalten
 
Andrei01:

Der Editor erzeugt die folgenden Warnungen zu diesem standardmäßigen, legalen und beliebten Konstrukt gemäß den C-Sprachstandards: "declaration of 'a' hides global declaration at line 4" und "declaration of 'b' hides global declaration at line 4", was ebenfalls nicht korrekt ist und vom Kern nicht verstanden wird, da es weder die Deklaration einer neuen Variablen innerhalb einer Funktion noch irgendeinen Hinweis auf eine mögliche Überschneidung von Variablen gibt.

Dies führt dazu, dass selbst in einem nicht sehr umfangreichen Programmcode Hunderte von irrelevanten Warnungen auftreten.

Die Meldungen sind zu 100 % richtig.

Man braucht 5-10 Jahre aktives Programmieren mit voller Verantwortung für seinen Code, um die Nützlichkeit der tiefen Kontrolle von Compilern zu schätzen. Die Sprachen C/C++ haben sich den Ruf, ein Selbstläufer zu sein, zu einem nicht geringen Teil durch schwache Compiler erworben, die nicht willens und in der Lage waren, die Qualität tiefgehend zu analysieren und die Autoren zu schützen.

Selbst jetzt, im Jahr 2014, sind C/C++-Compiler (die in Windows verblieben sind, nachdem sie von Microsoft vollständig zerstört wurden) nicht dazu da, Programmierer vor sich selbst zu schützen. Ja, es gibt eine schwache (praktisch nutzlos), für etwas Geld und separat laufen Code Analysis in Visial Studio, aber wir haben noch separat PVS Studio (Gott sei Dank für diese Jungs), CPP Check und Lint für tiefe Fehlersuche zu verwenden.

Testen Sie dieses Beispiel:

  • MQL4/MQL5 - gibt Warnungen über mögliche Fehler aus
    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, einschließlich Code Analysis - nichts. Die Qualität der Analyse für potenzielle Fehler ist gleich null. Sie machen sich nicht die Mühe, da es seit langem keinen Konkurrenten mehr gibt.

  • PVS Studio - meldet korrekt.
    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 - meldet dasselbe, aber das 'x' wird ausgeblendet.


Unsere Aufgabe ist es, einen Qualitätscompiler zu entwickeln, der gut in der Qualitätskontrolle ist und der die selbstmörderischen/verrückten Techniken der C/C++-Sprachen nicht zulässt.

 
Renat:

Ich denke auch, dass die Nachrichten völlig nutzlos sind. Ich bin kein professioneller Programmierer, aber diese Art von Unsinn in µl macht mir zu schaffen. Ich frage mich, ob PVS Studio eine Warnung ausgeben wird, wenn die Verweise auf a und b konstant sind (ich habe keine Möglichkeit, dies selbst zu überprüfen)?

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:

Prüfung dieses Beispiels:

  • MQL4/MQL5 - gibt Warnungen vor einem möglichen Fehler

1. Könnten Sie ein Beispiel dafür geben, was genau der mögliche Fehler in diesem einfachen Code sein könnte, vor dem der Compiler warnt?

Die Betreuung von Programmierern ist sicherlich eine gute Sache, vorausgesetzt, es gibt eine vernünftige logische Erklärung dafür und sie wird nicht zu aufdringlich.

2. Ich denke, dass die Qualität des geschriebenen Codes nicht mit der Qualität des Compilers und seiner Fähigkeit zur Syntaxanalyse zusammenhängt, sondern nur dann gegeben ist, wenn die Testumgebung gut genug geschrieben ist, um eine tiefgehende funktionale Analyse des geschriebenen Codes zu ermöglichen. Aber der Glaube an eine rettende syntaktische Analyse des Codes ohne eine Testschale ist Utopie und eine Verschwendung von Anstrengungen.

Das ist der Grund, warum professionelle Programmierer fast nie auf die Warnungen achten, denn Compiler können per Definition keine funktionale Analyse des Codes durchführen, während selbst ein unerfahrener Programmierer die Syntax der Sprache ohnehin kennt.

 
Renat:

Die Meldungen sind zu 100 % richtig.

Sie sind zwar richtig, aber sie sind nicht praktisch. Wichtig ist auch, dass dieses Verhalten des Compilers nicht kontrolliert werden kann.

Renat:

Man braucht 5-10 Jahre aktives Programmieren mit voller Verantwortung für den eigenen Code, um den Nutzen von Deep Control für Compiler zu erkennen. Die Sprachen C/C++ verdanken ihren Ruhm als Selbstschussanlage nicht zuletzt den schwachen Compilern, die nicht willens und in der Lage waren, die Qualität gründlich zu analysieren und die Autoren zu schützen.

Ich frage mich, warum genau diese Sprachen als Grundlage für MQL4/MQL4++/MQL5 genommen wurden?

Schließlich geht es nicht in erster Linie um Compiler, sondern um das Design dieser Sprachen.

Renat:

Selbst jetzt, im Jahr 2014, sind die C/C++-Compiler (die in Windows verblieben sind, nachdem sie von Microsoft vollständig zerstört wurden) nicht dazu da, Programmierer vor sich selbst zu schützen. Ja, es gibt eine schwache (praktisch nutzlos), für etwas Geld und separat laufen Code Analysis in Visial Studio, aber wir haben immer noch separat PVS Studio (Gott sei Dank für diese Jungs), CPP Check und Lint für tiefe Fehlererkennung zu verwenden.

Prüfung dieses Beispiels:

  • MQL4/MQL5 - gibt Warnungen über mögliche Fehler aus

  • Visual Studio 2012, einschließlich Code Analysis - nichts, die Qualität der Analyse für potenzielle Fehler ist gleich Null. Sie machen sich nicht die Mühe, da es lange Zeit keine Konkurrenten gibt.

  • PVS Studio - meldet korrekt

  • Lint - es erzeugt das gleiche, also das 'x' ausblenden...

Erstens ist Microsoft nicht omnipotent und allgegenwärtig. Und zweitens gibt es noch andere Compiler für Windows. Ich gebe Ihnen ein Beispiel, obwohl ich es unter Linux kompiliere, aber die Windows- und Linux-Versionen dieses Compilers unterscheiden sich nicht in der "tiefen Fehlersuche". Der Quellcode ist leicht verändert:

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

Kompilierung und Compiler-Meldungen:

$ 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){        
                       ^

Im Jahr 2014 gibt es Windows-Compiler, die über den Dienst "Deep Search" verfügen.

Beachten Sie, dass es dem Programmierer überlassen bleibt, ob er die "Tiefensuche" verwenden möchte oder nicht: Derselbe Code wird in der praktischeren Kompilierung ohne die Option "-Wremarks", aber mit allen Warnungen, die mit der Option "-Wall" aktiviert wurden, ohne Kommentare kompiliert:

$ icpc -c -Wall 1.cpp
$

Darüber hinaus erlaubt dieser Compiler, die "Tiefensuche" auf der Ebene der einzelnen Bemerkungen zu steuern und diejenigen zu deaktivieren, die der Programmierer für unnötig hält.

Es wird die folgende Version des Compilers verwendet:

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

Dieser Compiler lässt sich übrigens in Visual Studio integrieren, zumindest haben frühere Versionen von Visual Studio dies getan.

Renat:

Unsere Aufgabe ist es, einen Qualitätscompiler zu entwickeln, der gut in der Qualitätskontrolle ist und der die selbstmörderischen/verrückten Techniken der C/C++-Sprachen nicht zulässt.

Ein guter Compiler muss in erster Linie "funktionieren", d.h. er muss der Definition der Sprache entsprechen, sonst verlieren alle anderen Funktionen ihren Sinn:

#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() {
}

Warum wird die Methode f(), die im privaten Bereich deklariert ist, wie es sich gehört, von einer statischen Methode aufgerufen, aber der Klassenkonstruktor, der ebenfalls im privaten Bereich deklariert ist, wird bei der Definition einer Variablen von derselben statischen Methode "nicht aufgerufen"?

Fehlermeldungen:

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

Dieser Compiler-Bug erlaubt es zum Beispiel nicht, Myers' Singleton auf menschliche Weise zu implementieren (dieses Beispiel ist KEINE Implementierung des besagten Singletons). Und dies ist nicht der letzte Fehler in Bezug auf den Zugang zu Entitäten, die im privaten Bereich deklariert sind.

Es handelt sich dabei um einen Fehler und nicht um eine Funktion, die beispielsweise gegen selbstmörderische/unvernünftige Techniken gerichtet ist, denn sobald man die automatische Variablendefinition durch die dynamische Objekterzeugung ersetzt, wird der Konstruktor plötzlich auf die wunderbarste Weise aufgerufen:

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

    a.f();
    delete a;
  }

Dieser Code lässt sich bereits ohne Fehler kompilieren. Sie können auch überprüfen, ob der Konstruktor in diesem Fall bereits aufgerufen wird, indem Sie einen Ausdruck einer Nachricht aus dem Konstruktorcode einfügen.

Solange solche Fehler bestehen, ist es seltsam, von einem Qualitätscompiler zu sprechen. Wenn es um Fehler in der Sprachimplementierung selbst geht, sind C/C++-Compiler, sowohl kommerzielle als auch nicht-kommerzielle, den MQL4++-Compilern weit überlegen, weil es in ihnen keinen solchen Unsinn gibt. So viel besser, dass ich sagen würde, dass der MQL4++-Compiler im Vergleich zu ihnen überhaupt nicht "funktioniert".

Das einzige wirklich starke Merkmal des MQL4++-Compilers, das in diesem Stadium eine wirklich ernsthafte Kontrolle der Codequalität bietet, sind Warnungen für den Fall, dass der Programmierer die Rückgabewerte von Funktionen nicht kontrolliert, die fehlschlagen können, z. B. Handelsfunktionen. Aber selbst ein so starkes Merkmal des Compilers ist von sehr begrenztem Wert, wenn die Qualität seiner Implementierung so schlecht ist.

 
Pavlick:

Ich denke auch, dass die Nachrichten völlig nutzlos sind. Ich bin kein professioneller Programmierer, aber diese Art von Unsinn in µl macht mir zu schaffen. Ich frage mich, ob PVS Studio eine Warnung ausgeben wird, wenn die Verweise auf a und b konstant sind (ich habe keine Möglichkeit, dies selbst zu überprüfen)?

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);
}
Der Intel C++ 15.0.0 Compiler erzeugt für beide Fälle die gleichen Bemerkungen, wenn er mit der Option -Wremarks kompiliert.
 
simpleton:

Sie sind zwar treu, aber nicht praktisch.

Nun, wenn die Hinweise auf mögliche Fehler richtig sind, dann müssen diese Fehler korrigiert werden.
 
Renat:
Nun, wenn die Hinweise auf mögliche Fehler richtig sind, dann müssen diese Fehler behoben werden.

Ein potenzieller Fehler ist genau das: ein potenzieller Fehler ist nicht unbedingt ein Fehler. Daher ist die Aussage "das bedeutet, dass wir diese Fehler beheben müssen" nicht korrekt, da es sich möglicherweise gar nicht um Fehler handelt.

Es gibt Fälle, in denen mit ziemlicher Sicherheit ein Fehler vorliegt, z. B. wenn das Ergebnis eines Funktionsaufrufs nicht geprüft wird, was zu einem Fehlschlag führen kann. Eine Warnung vor einem solchen Fall ist sowohl angebracht als auch sehr nützlich. Warnungen über Fälle, in denen man nicht mit Sicherheit sagen kann, ob ein Fehler vorliegt oder nicht, sind in der Regel sowohl irrelevant als auch nicht nützlich. Wenn Namen zurückgehalten werden, kann man nicht sagen, dass es sich mit Sicherheit um einen Fehler handelt.

Ja, es ist für einen Programmierer möglich, alle Arten von Diagnosen auf einer "Deep Search"-Basis zu erhalten, um festzustellen, ob es potentielle Fehler gibt, d.h. - versehentlich gemachte Fehler. Dies darf jedoch nicht der Hauptcompilermodus sein, und es muss möglich sein, ihn zu deaktivieren. Um Neulinge vor möglichen Fehlern dieser Art zu schützen, kann die Diagnose standardmäßig, d.h. nach der Installation, aktiviert werden. Sie sollten sie aber trotzdem ausschalten können.

Es ist offensichtlich, dass die Tatsache, dass ein Name in einem eingeschlossenen Bereich versteckt wird, der zuvor im äußeren Bereich deklariert wurde, vom Intel-Compiler als bloße Bemerkung und nicht als Warnung erkannt wird, und zwar aus demselben Grund: Sie könnten überhaupt KEINE Fehler sein. Und in anderen Compilern, auch in nicht-kommerziellen, werden solche versteckten Fakten NICHT mit einer Warnung versehen. Denn die kollektive Erfahrung der Compiler-Benutzer, d.h. der Programmierer, sagt uns, dass dies KEINE Warnung sein sollte. Und natürlich sollte der Benutzer die Möglichkeit haben, zu konfigurieren, welche Warnungen/Hinweise ausgegeben werden sollen und welche nicht.

Übrigens, da MQL eine eigene Sprache ist, die nicht den C/C++-Standards folgen muss, wäre es nicht einfacher, das Ausblenden von Namen in eingeschlossenen Bereichen darin zu deaktivieren?

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

Diese Bemerkung ist bedeutungslos und gibt dem Programmierer im Prinzip keine nützliche Information, denn die Variable "a" wird nicht, wie angegeben, zunächst verborgen.

Das Ausblenden erfolgt nur, wenn eine lokale Kopie der Variablen erstellt wird, was ebenfalls eine rechtmäßige Aktion ist. Selbst wenn durch dieses Verstecken plötzlich ein Fehler im Code auftritt, kann er leicht gefunden werden, weil die Suche sofort denselben Namen findet. Wenn wir anfangen, die Namen in einer Funktionsschablone zu ändern, was eine "Lösung" für diese Regel durch die Compilerlogik ist, wird die Fehlersuche viel komplizierter und es wird viel Verwirrung beim Verständnis des Codes geben. Das scheint offensichtlich.

12345678910111213...16
Neuer Kommentar