Adiós robot - hola marasmo - página 6

Nuevo comentario
 
pansa:

¡Hola Vinin!

Ha comprobado el indicador: AltrTrend_Signal_v2_2.mq4

y encontró un error lógico

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

usted subrayó 1 al final

¿qué crees que debería ser?

pansa



¡Probablemente 0! ¡Inténtalo! Y si en un bucle, prueba y i o lo que sea cuenta!
 
pansa:

¡Hola Vinin!

Ha comprobado el indicador: AltrTrend_Signal_v2_2.mq4

y encontró un error lógico

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

usted subrayó 1 al final

¿qué crees que debería ser?

pansa



Debecambiar
 
Andrei01:

El editor genera las siguientes advertencias sobre esta construcción estándar, legal y popular según los estándares del lenguaje C: "la declaración de 'a' oculta la declaración global en la línea 4" y "la declaración de 'b' oculta la declaración global en la línea 4", lo cual también es incorrecto y analfabeto por parte del núcleo porque no hay ni declaración de una nueva variable dentro de una función ni ninguna pista sobre una posible superposición de variables.

Como resultado, incluso en un código de programa no muy grande tenemos cientos de advertencias irrelevantes.

Los mensajes son absolutamente correctos al 100%.

Se necesitan entre 5 y 10 años de programación activa con plena responsabilidad de su código para que alguien aprecie la utilidad del control profundo de los compiladores. Los lenguajes C/C++ se han ganado en gran medida la fama de ser una herramienta que se dispara a sí misma por culpa de unos compiladores débiles que no querían ni podían analizar en profundidad la calidad y proteger a los autores.

Incluso ahora, en 2014, los compiladores C/C++ (los que quedaron en Windows después de que Microsoft los destruyera por completo) no se dedican a proteger a los programadores de sí mismos. Sí, hay un débil (prácticamente inútil), por un poco de dinero y por separado ejecutar el análisis de código en Visial Studio, pero todavía tenemos que utilizar por separado PVS Studio (alabado sea Dios por esos chicos), CPP Check y Lint para la búsqueda profunda de errores.

Probando este ejemplo:

  • MQL4/MQL5 - da avisos sobre posibles errores
    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, incluyendo el Análisis de Código - nada. La calidad del análisis para los errores potenciales es cero. No se molestan porque hace tiempo que no hay competidores.

  • PVS Studio - informa correctamente.
    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 - informa de lo mismo, pero la 'x' se esconde.


Nuestra tarea es hacer un compilador de calidad que sea bueno en el control de calidad y que no permita las técnicas suicidas/insanas de los lenguajes C/C++.

 
Renat:

También creo que los mensajes son completamente inútiles. No soy un programador profesional, pero estas tonterías en µl me estresan. Me pregunto si las referencias a y b son constantes, ¿Generará PVS Studio una advertencia (no hay manera de comprobarlo yo mismo)?

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:

Prueba de este ejemplo:

  • MQL4/MQL5 - avisa de un posible error

1. ¿Podría dar un ejemplo de cuál podría ser exactamente el error potencial en este sencillo código, sobre el que advierte el compilador?

Cuidar a los programadores es ciertamente algo bueno, siempre que tenga una explicación lógica razonable y no se convierta en algo demasiado molesto.

2. Creo que la calidad del código escrito no está relacionada con la calidad del compilador y su capacidad para analizar la sintaxis, sino que sólo se produce cuando el entorno de prueba está escrito lo suficientemente bien como para poder realizar un análisis funcional profundo del código escrito. Pero creer en un análisis sintáctico salvador del código sin una cáscara de prueba es una utopía y un desperdicio de esfuerzos.

Por eso los programadores profesionales casi nunca miran las advertencias, ya que los compiladores, por definición, no pueden proporcionar un análisis funcional del código, mientras que incluso un programador novato conoce la sintaxis del lenguaje de todos modos.

 
Renat:

Los mensajes son absolutamente correctos al 100%.

Son correctos, pero no son prácticos. También es muy importante que este comportamiento del compilador no pueda ser controlado.

Renat:

Se necesitan entre 5 y 10 años de programación activa con plena responsabilidad de su código para que alguien aprecie la utilidad del control profundo de los compiladores. Los lenguajes C/C++ se ganaron en gran medida la fama de ser una herramienta que se dispara a sí misma por culpa de unos compiladores débiles que no querían ni podían analizar en profundidad la calidad y proteger a los autores.

Me pregunto por qué se tomaron exactamente estos lenguajes como base para MQL4/MQL4++/MQL5.

Al fin y al cabo, no se trata de los compiladores en primer lugar, sino del diseño de esos lenguajes.

Renat:

Incluso ahora, en 2014, los compiladores de C/C++ (los que quedaron en Windows después de que Microsoft los destruyera por completo) no se dedican a proteger a los programadores de sí mismos. Sí, hay un débil (prácticamente inútil), por un poco de dinero y por separado ejecutar el análisis de código en Visial Studio, pero todavía tenemos que utilizar por separado PVS Studio (alabado sea Dios por esos chicos), CPP Check y Lint para la búsqueda profunda de errores.

Prueba de este ejemplo:

  • MQL4/MQL5 - da avisos sobre posibles errores

  • Visual Studio 2012, incluyendo el Análisis de Código - nada, la calidad del análisis para posibles errores es nula. No se molestan ya que no hay competidores durante mucho tiempo.

  • PVS Studio - informa correctamente

  • Lint - genera lo mismo, así que la 'x' se esconde...

En primer lugar, Microsoft no es omnipotente ni omnipresente. Y en segundo lugar, quedan otros compiladores en Windows. Te pongo un ejemplo, aunque lo compilo desde Linux, pero las versiones de Windows y Linux de este compilador no difieren en la parte de "búsqueda profunda de errores". El código fuente está ligeramente modificado:

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

Mensajes de compilación y del compilador:

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

Verás, en 2014, hay compiladores para Windows que tienen el servicio de "búsqueda profunda de errores".

Tenga en cuenta que el derecho a decidir si se utiliza la "búsqueda profunda" o no se da al programador: el mismo código en la compilación más práctica sin la opción "-Wremarks", pero con todas las advertencias activadas con la opción "-Wall" compila sin ningún comentario:

$ icpc -c -Wall 1.cpp
$

Además, este compilador permite controlar la "búsqueda profunda" a nivel de observaciones individuales, desactivando aquellas que el programador considere innecesarias.

Se utiliza la siguiente versión del compilador:

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

Por cierto, este compilador se integra con Visual Studio, al menos las versiones anteriores solían integrarse con versiones anteriores de Visual Studio.

Renat:

Nuestra tarea es hacer un compilador de calidad que sea bueno en el control de calidad y que no permita las técnicas suicidas/insanas de los lenguajes C/C++.

Un compilador de calidad, en primer lugar, debe "funcionar", es decir, debe corresponder a la definición del lenguaje, de lo contrario todas sus demás características perderán su sentido:

#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 qué el método f() declarado en la sección privada es llamado perfectamente desde un método estático como debería ser, pero el constructor de la clase, también declarado en la sección privada, "no es llamado" desde el mismo método estático al definir una variable?

Mensajes de error:

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

Este error del compilador no permite, por ejemplo, implementar el singleton de Myers de forma humana (este ejemplo NO es una implementación de dicho singleton). Y este no es el último fallo en cuanto al acceso a las entidades declaradas en la sección privada.

Esto es exactamente un error, y no una característica dirigida, por ejemplo, contra las técnicas suicidas/no razonables, porque una vez que se sustituye la definición automática de variables por la creación dinámica de objetos, el constructor es llamado de repente de la manera más maravillosa:

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

    a.f();
    delete a;
  }

Este código ya se compila sin errores. Además, puedes asegurarte de que el constructor ya está siendo llamado en este caso insertando una impresión de algún mensaje del código del constructor.

Mientras sigan existiendo estos fallos, es extraño hablar de un compilador de calidad. Cuando se trata de errores en la propia implementación del lenguaje, los compiladores de C/C++, tanto comerciales como no comerciales, son muy superiores a los compiladores de MQL4++ porque en ellos no hay esas tonterías. Tanto mejor, que diría que comparado con ellos el compilador MQL4++ 'no funciona' en absoluto.

La única característica realmente fuerte del compilador MQL4++ que proporciona un control realmente serio de la calidad del código en esta etapa son las advertencias en caso de que el programador no controle los valores de retorno de las funciones que pueden fallar, por ejemplo, las funciones de comercio. Pero incluso una característica tan fuerte del compilador tiene un valor muy limitado cuando la calidad de su implementación es tan pobre.

 
Pavlick:

También creo que los mensajes son completamente inútiles. No soy un programador profesional, pero estas tonterías en µl me estresan. Me pregunto si las referencias a y b son constantes, ¿Generará PVS Studio una advertencia (no hay manera de comprobarlo yo mismo)?

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);
}
El compilador Intel C++ 15.0.0 produce las mismas observaciones para ambos casos cuando se compila con la opción -Wremarks.
 
simpleton:

Son fieles, pero no prácticos.

Pues bien, si los indicios de posibles errores son correctos, es necesario corregirlos.
 
Renat:
Pues bien, si los indicios de posibles errores son correctos, habrá que corregirlos.

Un error potencial es sólo eso, un error potencial no es necesariamente un error. Por lo tanto, la afirmación de que "significa que tenemos que arreglar estos errores" es incorrecta, porque pueden NO ser errores en absoluto.

Hay casos en los que es casi seguro que haya un error, por ejemplo, cuando no se comprueba el resultado de una llamada a una función, que puede fallar. Una advertencia sobre este caso es apropiada y bastante útil. Las advertencias sobre casos en los que no se puede saber con certeza si hay un error o no suelen ser irrelevantes y poco útiles. Cuando se ocultan los nombres, no se puede decir que haya un error casi seguro.

Sí, es posible que un programador obtenga todo tipo de diagnósticos en una "búsqueda profunda" para determinar si hay errores potenciales, es decir, errores cometidos inadvertidamente. Pero este no debe ser el modo principal del compilador y debe ser posible desactivarlo. Para proteger a los novatos de posibles errores de este tipo, el diagnóstico puede activarse por defecto, es decir, después de la instalación. Sin embargo, deberías poder desactivarlo.

Es obvio que los hechos de ocultar un nombre en un ámbito cerrado que fue declarado previamente en el ámbito externo son detectados por el compilador de Intel como meras observaciones y no como advertencias por la misma razón: podrían NO ser errores en absoluto. Y en otros compiladores, incluidos los no comerciales, tales ocultamientos NO se corresponden con ninguna advertencia. Porque toda la experiencia colectiva de los usuarios de compiladores, es decir, de los programadores, nos dice que esto NO debería ser una advertencia. Y, por supuesto, el usuario debería poder configurar qué advertencias/observaciones se emitirán y cuáles no.

Por cierto, dado que MQL es un lenguaje independiente que no debe seguir los estándares de C/C++, ¿no sería más fácil desactivar la ocultación de nombres en ámbitos cerrados en él?

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

Esta observación carece de sentido y, en principio, no aporta ninguna información útil al programador, ya que no hay ocultación de la variable "a" inicialmente, como se ha dicho.

La ocultación sólo se produce cuando se crea una copia local de la variable, que también es una acción legítima. Incluso si de repente se produce un error en el código debido a esta ocultación, se puede encontrar fácilmente precisamente porque la búsqueda encuentra inmediatamente el mismo nombre. Si empezamos a cambiar y alterar los nombres en una plantilla de función, que es una "solución" a esta regla por la lógica del compilador, la situación de búsqueda de errores se volverá mucho más complicada y abundará la confusión en la comprensión del código. Parece obvio.

12345678910111213...16
Nuevo comentario