Addio robot - ciao marasma - pagina 6

Nuovo commento
 
pansa:

Ciao Vinin!

Hai controllato l'indicatore: AltrTrend_Signal_v2_2.mq4

e ha trovato un errore logico

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

hai sottolineato 1 alla fine

cosa pensi che dovrebbe essere?

pansa



Probabilmente 0! Provate! E se in un ciclo, provate e i o quello che conta!
 
pansa:

Ciao Vinin!

Hai controllato l'indicatore: AltrTrend_Signal_v2_2.mq4

e ha trovato un errore logico

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

hai sottolineato 1 alla fine

cosa pensi che dovrebbe essere?

pansa



Devespostarsi
 
Andrei01:

L'editor genera i seguenti avvertimenti su questo costrutto standard, legale e popolare secondo gli standard del linguaggio C: "declaration of 'a' hides global declaration at line 4" e "declaration of 'b' hides global declaration at line 4" che è anche scorretto e analfabeta dal nucleo perché non c'è né dichiarazione di una nuova variabile all'interno di una funzione né alcun accenno a una possibile sovrapposizione di variabili.

Di conseguenza, anche in un codice di programma non molto grande abbiamo centinaia di avvisi irrilevanti.

I messaggi sono assolutamente corretti al 100%.

Avete bisogno di 5-10 anni di programmazione attiva con piena responsabilità per il vostro codice a qualcuno per apprezzare l'utilità del controllo profondo dei compilatori. I linguaggi C/C++ hanno in gran parte guadagnato la fama di essere uno strumento di autocombustione a causa di compilatori deboli che non volevano e non potevano analizzare profondamente la qualità e proteggere gli autori.

Anche ora, nel 2014, i compilatori C/C++ (quelli rimasti su Windows dopo che sono stati completamente distrutti da Microsoft) non si occupano di proteggere i programmatori da se stessi. Sì, c'è un debole (praticamente inutile), per un po' di soldi ed eseguire separatamente Code Analysis in Visial Studio, ma dobbiamo ancora usare separatamente PVS Studio (lode a Dio per quei ragazzi), CPP Check e Lint per la ricerca profonda degli errori.

Testare questo esempio:

  • MQL4/MQL5 - dà avvisi su potenziali errori
    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, compresa l'analisi del codice - niente. La qualità dell'analisi per i potenziali errori è zero. Non si preoccupano perché non c'è un concorrente da molto tempo.

  • PVS Studio - riporta correttamente.
    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 - riporta la stessa cosa, ma la 'x' si nasconde.


Il nostro compito è quello di fare un compilatore di qualità che sia bravo nel controllo della qualità e che non permetta le tecniche suicide/insane dei linguaggi C/C++.

 
Renat:

Penso anche che i messaggi siano completamente inutili. Non sono un programmatore professionista, ma questo tipo di assurdità in µl mi stressa. Mi chiedo se i riferimenti ad a e b sono costanti, PVS Studio genererà un avviso (non c'è modo di controllarlo da solo)?

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 di questo esempio:

  • MQL4/MQL5 - dà avvisi di un potenziale errore

1. Potresti fare un esempio di quale potrebbe essere esattamente l'errore potenziale in questo semplice codice, di cui il compilatore avverte?

Occuparsi dei programmatori è certamente una buona cosa, purché abbia una spiegazione logica ragionevole e non diventi troppo invadente.

2. Penso che la qualità del codice scritto non sia legata alla qualità del compilatore e alla sua capacità di analizzare la sintassi, ma si verifica solo quando l'ambiente di test è scritto abbastanza bene da permettere di eseguire una profonda analisi funzionale del codice scritto. Ma credere in una salvifica analisi sintattica del codice senza una shell di test è un'utopia e uno spreco di sforzi.

Ecco perché i programmatori professionisti non guardano quasi mai gli avvertimenti perché i compilatori, per definizione, non possono fornire un'analisi funzionale del codice, mentre anche un programmatore principiante conosce comunque la sintassi del linguaggio.

 
Renat:

I messaggi sono assolutamente corretti al 100%.

Sono corretti, ma non sono pratici. È anche molto importante che questo comportamento del compilatore non possa essere controllato.

Renat:

Avete bisogno di 5-10 anni di programmazione attiva con piena responsabilità per il vostro codice a qualcuno per apprezzare l'utilità del controllo profondo per i compilatori. I linguaggi C/C++ si sono guadagnati non poco la fama di essere uno strumento autocelebrativo a causa di compilatori deboli che non volevano e non erano in grado di analizzare profondamente la qualità e proteggere gli autori.

Mi chiedo perché esattamente questi linguaggi sono stati presi come base per MQL4/MQL4++/MQL5?

Dopo tutto, non si tratta di compilatori in primo luogo, ma del design di questi linguaggi.

Renat:

Anche ora, nel 2014, i compilatori C/C++ (quelli rimasti su Windows dopo che sono stati completamente distrutti da Microsoft) non si occupano di proteggere i programmatori da se stessi. Sì, c'è un debole (praticamente inutile), per un po' di soldi e separatamente eseguire l'analisi del codice in Visial Studio, ma dobbiamo ancora usare separatamente PVS Studio (lode a Dio per quei ragazzi), CPP Check e Lint per la rilevazione profonda degli errori.

Test di questo esempio:

  • MQL4/MQL5 - dà avvisi su potenziali errori

  • Visual Studio 2012, compresa l'analisi del codice - niente, la qualità dell'analisi per i potenziali errori è zero. Non si preoccupano perché non ci sono concorrenti per molto tempo.

  • PVS Studio - riporta correttamente

  • Lint - genera la stessa cosa, quindi la 'x' si nasconde...

In primo luogo, Microsoft non è onnipotente e onnipresente. E secondo, ci sono altri compilatori rimasti su Windows. Vi darò un esempio, anche se lo compilo da sotto Linux, ma le versioni Windows e Linux di questo compilatore non differiscono nella parte di "ricerca profonda degli errori". Il codice sorgente è leggermente modificato:

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

Compilazione e messaggi del compilatore:

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

Vedete, nel 2014, ci sono compilatori di Windows che hanno il servizio di "ricerca profonda".

Si noti che il diritto di decidere se usare o meno il "deep lookup" è dato al programmatore: lo stesso codice in compilazione più pratica senza l'opzione "-Wremarks" ma con tutti gli avvertimenti abilitati con l'opzione "-Wall" si compila senza alcun commento:

$ icpc -c -Wall 1.cpp
$

Inoltre, questo compilatore permette di controllare la "ricerca profonda" a livello di singole osservazioni, disabilitando quelle che il programmatore considera inutili.

Viene utilizzata la seguente versione del compilatore:

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

A proposito, questo compilatore si integra con Visual Studio, almeno le versioni precedenti si integravano con le versioni precedenti di Visual Studio.

Renat:

Il nostro compito è quello di fare un compilatore di qualità che sia bravo nel controllo della qualità e che non permetta le tecniche suicide/insane dei linguaggi C/C++.

Un compilatore di qualità, prima di tutto, deve "funzionare", cioè deve corrispondere alla definizione del linguaggio, altrimenti tutte le sue altre caratteristiche perderebbero di significato:

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

Perché il metodo f() dichiarato nella sezione privata è chiamato perfettamente da un metodo statico come dovrebbe essere, ma il costruttore della classe, anch'esso dichiarato nella sezione privata, non è "chiamato" dallo stesso metodo statico quando si definisce una variabile?

Messaggi di errore:

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

Questo bug del compilatore non permette, per esempio, di implementare il singleton di Myers in modo umano (questo esempio NON è un'implementazione di detto singleton). E questo non è l'ultimo bug in termini di accesso alle entità dichiarate nella sezione privata.

Questo è esattamente un bug, e non una qualche caratteristica diretta, per esempio, contro le tecniche suicide/irragionevoli, perché una volta che si sostituisce la definizione automatica delle variabili con la creazione dinamica degli oggetti, il costruttore viene improvvisamente chiamato nel modo più meraviglioso:

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

    a.f();
    delete a;
  }

Questo codice si compila già senza errori. Inoltre, potete assicurarvi che il costruttore sia già stato chiamato in questo caso inserendo una stampa di qualche messaggio dal codice del costruttore.

Finché rimangono tali bug, è strano parlare di un compilatore di qualità. Quando si tratta di errori nell'implementazione del linguaggio stesso, i compilatori C/C++, sia commerciali che non, sono di gran lunga superiori ai compilatori MQL4++ perché non ci sono queste sciocchezze. Così tanto meglio, che direi che rispetto a loro il compilatore MQL4++ 'non funziona' affatto.

L'unica caratteristica veramente forte del compilatore MQL4++ che fornisce un controllo veramente serio della qualità del codice in questa fase sono gli avvertimenti nel caso in cui il programmatore non controlli i valori di ritorno delle funzioni che possono fallire, per esempio le funzioni di trading. Ma anche una caratteristica così forte del compilatore ha un valore molto limitato quando la qualità della sua implementazione è così scarsa.

 
Pavlick:

Penso anche che i messaggi siano completamente inutili. Non sono un programmatore professionista, ma questo tipo di assurdità in µl mi stressa. Mi chiedo se i riferimenti ad a e b sono costanti, PVS Studio genererà un avviso (non c'è modo di controllarlo da solo)?

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);
}
Il compilatore Intel C++ 15.0.0 produce gli stessi commenti per entrambi i casi quando compila con l'opzione -Wremarks.
 
simpleton:

Fedeli, ma non pratici.

Bene, se le indicazioni di potenziali errori sono corrette, allora è necessario correggere questi errori.
 
Renat:
Beh, se le indicazioni di potenziali errori sono corrette, allora questi errori devono essere corretti.

Un errore potenziale è proprio questo, un errore potenziale non è necessariamente un errore. Pertanto, l'affermazione che "significa che dobbiamo correggere questi errori" non è corretta, perché potrebbero NON essere affatto errori.

Ci sono casi in cui un errore è quasi certamente presente, per esempio, quando non viene controllato il risultato di una chiamata di funzione, che può fallire. Un avvertimento su un caso del genere è appropriato e abbastanza utile. Gli avvertimenti sui casi in cui non si può dire con certezza se c'è un errore o no sono di solito sia irrilevanti che non utili. Quando i nomi sono nascosti, non si può dire che c'è quasi certamente un errore.

Sì, è possibile per un programmatore ottenere ogni sorta di diagnostica basata sulla "ricerca profonda" per determinare se ci sono errori potenziali, cioè - errori fatti inavvertitamente. Ma questa non dovrebbe essere la modalità principale del compilatore e dovrebbe essere possibile disabilitarla. Per proteggere i novizi da potenziali errori di questo tipo, la diagnostica può essere abilitata di default, cioè dopo l'installazione. Tuttavia, si dovrebbe essere ancora in grado di spegnerlo.

È ovvio che i fatti di nascondere un nome in uno scope chiuso che è stato precedentemente dichiarato nello scope esterno sono rilevati dal compilatore Intel solo come marcature e non come avvertimenti per lo stesso motivo: potrebbero non essere affatto errori. E in altri compilatori, compresi quelli non commerciali, tali fatti nascosti NON corrispondono ad alcun avvertimento. Perché tutta l'esperienza collettiva degli utenti del compilatore, cioè dei programmatori, ci dice che questo NON dovrebbe essere un avvertimento. E, naturalmente, l'utente dovrebbe essere in grado di configurare quali avvertimenti/osservazioni saranno emessi e quali no.

A proposito, dato che MQL è un linguaggio separato che non deve seguire gli standard di C/C++, non sarebbe più facile disabilitare l'occultamento dei nomi negli ambiti chiusi in esso?

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

Questa osservazione non ha senso e non dà alcuna informazione utile al programmatore in linea di principio, perché non c'è alcun occultamento della variabile "a" inizialmente, come detto.

L'occultamento avviene solo quando viene creata una copia locale della variabile, che è anche un'azione legittima. Anche se un errore si verifica improvvisamente nel codice a causa di questo nascondersi, può essere facilmente trovato proprio perché la ricerca trova immediatamente lo stesso nome. Se cominciamo a cambiare e alterare i nomi in un modello di funzione, che è una "soluzione" a questa regola da parte della logica del compilatore, la situazione di ricerca degli errori diventerà molto più complicata e la confusione abbonderà nella comprensione del codice. Sembra ovvio.

12345678910111213...16
Nuovo commento
Motivazione: