Adeus robô - olá marasmus - página 6

Novo comentário
 
pansa:

Oi Vinin!

Você verificou o indicador: AltrTrend_Signal_v2_2.mq4

e encontrou um erro lógico

em fórmula : SSP=MathCeil (Kperiod/iADX(NULL,0,PerADX,PRICE_CLOSE,MODE_MAIN,1))

você sublinhou 1 no final

o que você acha que deveria ser?

pansa



Provavelmente 0! Tente! E se em um loop, tente e eu ou o que quer que seja que conte!
 
pansa:

Oi Vinin!

Você verificou o indicador: AltrTrend_Signal_v2_2.mq4

e encontrou um erro lógico

em fórmula : SSP=MathCeil (Kperiod/iADX(NULL,0,PerADX,PRICE_CLOSE,MODE_MAIN,1))

você sublinhou 1 no final

o que você acha que deveria ser?

pansa



Devemudar
 
Andrei01:

O editor gera os seguintes avisos sobre esta construção padrão, legal e popular de acordo com os padrões de linguagem C: "declaração de 'a' oculta declaração global na linha 4" e "declaração de 'b' oculta declaração global na linha 4", que também é incorreta e analfabeta pelo núcleo porque não há declaração de uma nova variável dentro de uma função nem qualquer dica sobre qualquer possível sobreposição de variáveis.

Como resultado, mesmo em um código de programa não muito grande, temos centenas de avisos irrelevantes.

As mensagens são absolutamente 100% corretas.

Você precisa de 5-10 anos de programação ativa com total responsabilidade por seu código a alguém para apreciar a utilidade de um controle profundo dos compiladores. Os idiomas C/C++ ganharam em grande parte a fama de ser uma ferramenta de autodidata por causa de compiladores fracos que não estavam dispostos e incapazes de analisar profundamente a qualidade e proteger os autores.

Mesmo agora, em 2014, os compiladores C/C++ (os que ficaram no Windows depois de terem sido completamente destruídos pela Microsoft) não estão no negócio de proteger os programadores de si mesmos. Sim, há um fraco (praticamente inútil), por algum dinheiro e executar análise de código separadamente no Visial Studio, mas ainda temos que usar separadamente PVS Studio (louvado a Deus por esses caras), CPP Check e Lint para busca de erros profundos.

Testando este exemplo:

  • MQL4/MQL5 - dá avisos sobre possíveis erros
    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, incluindo Análise de Código - nada. A qualidade da análise para erros potenciais é zero. Eles não se incomodam desde que não existe um concorrente há muito tempo.

  • PVS Studio - relata corretamente.
    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 - relata a mesma coisa, mas o 'x' esconde.


Nossa tarefa é fazer um compilador de qualidade que seja bom no controle de qualidade e que não permita as técnicas suicidas/insane das linguagens C/C++.

 
Renat:

Também acho que as mensagens são completamente inúteis. Não sou um programador profissional, mas este tipo de bobagem em µl me estressa. Será que as referências a e b são constantes, será que o PVS Studio irá gerar um aviso (não há maneira de verificá-lo eu mesmo)?

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:

Teste deste exemplo:

  • MQL4/MQL5 - dá avisos de um erro potencial

1. Você poderia dar um exemplo de qual poderia ser exatamente o erro potencial neste código simples, que o compilador adverte?

Cuidar dos programadores é certamente uma coisa boa, desde que tenha uma explicação lógica razoável e não se torne muito intrusiva.

2. Eu acho que a qualidade do código escrito não está relacionada à qualidade do compilador e sua capacidade de analisar a sintaxe, mas ocorre apenas quando o ambiente de teste está bem escrito, o que lhe permite realizar uma análise funcional profunda do código escrito. Mas a crença em uma análise sintática salvadora do código sem uma casca de teste é uma utopia e um desperdício de esforços.

É por isso que os programadores profissionais quase nunca olham os avisos para os compiladores, por definição, não podem fornecer uma análise funcional do código, enquanto mesmo um programador novato conhece a sintaxe da linguagem de qualquer maneira.

 
Renat:

As mensagens são absolutamente 100% corretas.

Elas são corretas, mas não são práticas. É também muito importante que este comportamento do compilador não possa ser controlado.

Renat:

Você precisa de 5-10 anos de programação ativa com total responsabilidade por seu código a alguém para apreciar a utilidade de um controle profundo para os compiladores. Os idiomas C/C++ em não pequena parte ganharam a fama de ser uma ferramenta de autodidata por causa de compiladores fracos que não estavam dispostos e incapazes de analisar profundamente a qualidade e proteger os autores.

Por que exatamente esses idiomas foram tomados como base para MQL4/MQL4++/MQL5?

Afinal, não se trata, em primeiro lugar, de compiladores, mas sim do design desses idiomas.

Renat:

Mesmo agora, em 2014, os compiladores C/C++ (os que ficaram no Windows depois de terem sido completamente destruídos pela Microsoft) não estão no negócio de proteger os programadores de si mesmos. Sim, há um fraco (praticamente inútil), por algum dinheiro e executar análise de código separadamente no Visial Studio, mas ainda temos que usar separadamente PVS Studio (louvado a Deus por esses caras), CPP Check e Lint para detecção de erros profundos.

Teste deste exemplo:

  • MQL4/MQL5 - dá avisos sobre possíveis erros

  • Visual Studio 2012, incluindo Análise de Código - nada, a qualidade da análise para erros potenciais é zero. Eles não se incomodam, já que não há concorrentes há muito tempo.

  • PVS Studio - relata corretamente

  • Lint - gera a mesma coisa, por isso o 'x' esconde...

Primeiro, a Microsoft não é omnipotente e onipresente. E, em segundo lugar, restam outros compiladores no Windows. Vou lhe dar um exemplo, embora eu o compile sob Linux, mas as versões Windows e Linux deste compilador não diferem na parte "pesquisa de erros profundos". O código fonte é ligeiramente modificado:

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

Compilação e compilação de mensagens:

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

Veja, em 2014, existem compiladores para Windows que têm o serviço de "pesquisa de erros profundos".

Note que o direito de decidir se usar "pesquisa profunda" ou não é dado ao programador: o mesmo código na compilação mais prática sem a opção "-Wremarks", mas com todos os avisos habilitados com a opção "-Wall" compila sem nenhum comentário:

$ icpc -c -Wall 1.cpp
$

Além disso, este compilador permite controlar a "busca profunda" no nível das observações individuais, desabilitando aquelas que o programador considera desnecessárias.

É utilizada a seguinte versão do compilador:

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

A propósito, este compilador se integra com o Visual Studio, pelo menos versões anteriores dele eram utilizadas para se integrar com versões anteriores do Visual Studio.

Renat:

Nossa tarefa é fazer um compilador de qualidade que seja bom no controle de qualidade e que não permita as técnicas suicidas/insane das linguagens C/C++.

Um compilador de qualidade, antes de tudo, deve "funcionar", ou seja, deve corresponder à definição do idioma, caso contrário, todas as suas outras características perderão seu significado:

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

Por que o método f() é declarado na seção privada chamado perfeitamente a partir de um método estático como deveria ser, mas o construtor de classes, também declarado na seção privada, "não é chamado" a partir do mesmo método estático ao definir uma variável?

Mensagens de erro:

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

Este bug de compilador não permite, por exemplo, implementar o singleton de Myers de uma forma humana (este exemplo NÃO é uma implementação do referido singleton). E este não é o último bug em termos de acesso às entidades declaradas na seção privada.

Isto é exatamente um bug, e não alguma característica dirigida, por exemplo, contra técnicas suicidas/não razoáveis, porque uma vez que você substitui a definição automática de variáveis pela criação dinâmica de objetos, o construtor é chamado de repente da maneira mais maravilhosa:

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

    a.f();
    delete a;
  }

Este código já é compilado sem erros. Além disso, você pode ter certeza de que o construtor já está sendo chamado neste caso, inserindo uma impressão de alguma mensagem do código do construtor.

Enquanto tais insetos permanecerem, é estranho falar de um compilador de qualidade. Quando se trata de erros na própria implementação da linguagem, os compiladores C/C++, tanto comerciais quanto não comerciais, são muito superiores aos compiladores MQL4++ porque não há tal disparate neles. Muito melhor, eu diria que comparado a eles o compilador MQL4++ "não funciona" de forma alguma.

A única característica realmente forte do compilador MQL4++ que fornece um controle realmente sério da qualidade do código nesta fase são os avisos no caso do programador não controlar os valores de retorno das funções que podem falhar, por exemplo, as funções comerciais. Mas mesmo uma característica tão forte do compilador é de valor muito limitado quando a qualidade de sua implementação é tão pobre.

 
Pavlick:

Também acho que as mensagens são completamente inúteis. Não sou um programador profissional, mas este tipo de bobagem em µl me estressa. Será que as referências a e b são constantes, será que o PVS Studio irá gerar um aviso (não há maneira de verificá-lo eu mesmo)?

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);
}
O compilador Intel C++ 15.0.0 produz as mesmas observações para ambos os casos ao compilar com a opção -Wremarks.
 
simpleton:

São fiéis, mas não práticos.

Bem, se as indicações de erros potenciais estiverem corretas, então é necessário corrigir esses erros.
 
Renat:
Bem, se as indicações de erros potenciais estiverem corretas, então esses erros devem ser corrigidos.

Um erro potencial é apenas isso, um erro potencial não é necessariamente um erro em absoluto. Portanto, a afirmação de que "isso significa que temos que corrigir esses erros" é incorreta, pois eles podem NÃO ser erros de forma alguma.

Há casos em que um erro está quase certamente presente, por exemplo, quando o resultado de uma chamada de função não é verificado, o que pode falhar. Um aviso sobre tal caso é ao mesmo tempo apropriado e bastante útil. As advertências sobre casos onde não se pode ter certeza se há ou não um erro são geralmente tanto irrelevantes quanto inúteis. Quando os nomes são retidos, não se pode dizer que há quase certamente um erro.

Sim, é possível para um programador obter todos os tipos de diagnósticos em uma base de "pesquisa profunda" para determinar se existem erros potenciais, ou seja - inadvertidamente cometidos erros. Mas este não deveria ser o modo principal do compilador e deveria ser possível desativá-lo. A fim de proteger os novatos de erros potenciais deste tipo, o diagnóstico pode ser ativado por padrão, ou seja, após a instalação. No entanto, você ainda deve ser capaz de desligá-lo.

É óbvio que os fatos de esconder um nome em um escopo fechado que foi previamente declarado no escopo externo são detectados pelo compilador Intel apenas como marcações e não como avisos pelo mesmo motivo: eles NÃO poderiam ser erros de forma alguma. E em outros compiladores, incluindo os não comerciais, tais fatos ocultos NÃO correspondem a nenhum aviso. Porque toda a experiência coletiva dos usuários de compiladores, ou seja, programadores, nos diz que isto NÃO deve ser um aviso. E, é claro, o usuário deve ser capaz de configurar quais advertências/observações serão emitidas e quais não.

A propósito, como a MQL é uma linguagem separada que não deve seguir os padrões C/C++, não seria mais fácil desativar a ocultação de nomes em escopos fechados nela?

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

Esta observação não faz sentido e não dá nenhuma informação útil ao programador em princípio, pois não há ocultação da variável "a" inicialmente, como foi dito.

A ocultação ocorre somente quando uma cópia local da variável é criada, o que também é uma ação legítima. Mesmo que de repente ocorra um erro no código devido a este esconderijo, ele pode ser facilmente encontrado precisamente porque a busca encontra imediatamente o mesmo nome. Se começarmos a mudar e alterar os nomes em um modelo de função, que é uma "solução" para esta regra pela lógica do compilador, a situação de busca de erros se tornará muito mais complicada e a confusão abundará na compreensão do código. Parece óbvio.

12345678910111213...16
Novo comentário