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

Nuevo comentario
 

En cuanto a ocultar el nombre de la variable:

simpleton ya escribió sobre el compilador de intel, situación similar con gcc y clang. Cuando se compila en un modo muy estricto (en términos de presencia de mensajes):

gcc(clang) -Wall -Wextra

el compilador no se queja de este problema. Las quejas sobre la ocultación se activan con una opción separada -Sombra. Es decir, la comprobación en sí no es difícil en los compiladores de c++ (excepto MSVC). Pero no he visto ningún ide (basado en gcc, por ejemplo, qt creator, code blocks...) donde -Wshadow esté activado por defecto.

¿Por qué? Probablemente porque para la mayoría de la gente la utilidad de este mensaje es cuestionable.

 
Pavlick:

En cuanto a ocultar el nombre de la variable:

simpleton ya escribió sobre el compilador de intel, situación similar con gcc y clang. Cuando se compila en modo muy estricto (en términos de presencia de mensajes):

Parece que confundes el engañoso "modo estricto del compilador" y el trabajo real de los analizadores estáticos, ya que nunca los has utilizado.

El compilador completa la compilación en 1 o 2 minutos, mientras que los analizadores trabajan durante varias horas (PVS Studio) o decenas de horas (CPP Check) en el mismo código. De ahí que la calidad y la profundidad de los resultados sean tan diferentes.

 

Saludos a todos.

Hace casi un año que la "locura" y el marasmo de innovaciones en MQL4 no ha parado. "¡Pero sigue ahí! (с).

Antes culpaban a "Metaquotes" por el mal lenguaje, ahora les culpan por el exceso de "agua". Los problemas no han disminuido.

Puedo añadir lo siguiente de mi parte.

Para los comerciantes, los no programadores y los programadores principiantes, se puede implementar un algoritmo y un código sencillos.

Si tiene una gran base de índices, búhos, etc. que no compilan en las nuevas construcciones, entonces tiene sentido mirar de cerca y "sacudir sus arcas". Asegúrate de guardar las cosas más útiles y no escatimes en reescribirlas y depurarlas para las nuevas construcciones.

Los verdaderos programadores experimentados o los que quieren llegar a serlo, siempre siguen las innovaciones, los errores y los fallos son su pan. Escribir código sin errores es lo que cuenta como buena programación. Si no tiene la energía, el tiempo, la posibilidad o el deseo de captar todas las innovaciones de "Metakvot", utilice el lenguaje que domina. Las DLL no se han suprimido, introduzca sus propios algoritmos ajustados.

 
Andrei01:

Los entornos de prueba se utilizan ampliamente en los productos de software para la verificación funcional de los diseños de chips de software, donde los requisitos de calidad del código son muy altos. Además, una cáscara funcional es una parte integral de cualquier desarrollo de código de diseño de chips. Por otra parte, muchos programadores, cuando escriben proyectos de software habituales, ni siquiera tienen idea de estas pruebas funcionales, ya que escribir dichas pruebas desde cero puede llevar más tiempo que cuando se escribe el proyecto en sí y sólo se justifica cuando se requiere escribir código de alta calidad o hay muchas versiones del mismo proyecto. Por otro lado, un entorno de pruebas bien escrito ahorra mucho tiempo de depuración y verificación del código.

El análisis estático también se utiliza, pero sólo como una comprobación sintáctica muy superficial e inicial.

Los entornos de prueba son entornos de prueba. Un entorno de pruebas está "confinado" al producto que está probando.

Me refería a las herramientas generales, aquellas que "no tienen ni idea" del producto que se analiza y, por tanto, pueden analizar y encontrar problemas en cualquier producto.

 
Renat:

Simplón, qué tontería.

"Qué tontería" parece implicar un completo desajuste de actitudes.

Renat:

Sólo cuando se llegue al nivel de control de calidad total, se entenderá. Pero mientras tanto, mientras sigas en el nivel de percepción de un único programador egoísta, seguirás pensando "es razonable no controlarme, que el control sea por utilidades separadas nunca ejecutadas".

Entonces, ¿por qué el "control de calidad total" permite un nivel de control de calidad tan bajo?

Por ejemplo:

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }

public:
  static void method1() {
    //A a; // 'A::A' - cannot call private member function      3.mq4   10      7
  }

  static void method2() {
    A *a = new A; // А здесь private member function великолепно вызывается
    delete a;
  }
};

/******************************************************************************/
void OnStart() {
  A::method1();
  A::method2();
}

El constructor es llamado cuando se crea un objeto en el método2:

00:50:23 Script 3 EURUSDm,M5: loaded successfully
00:50:23 3 EURUSDm,M5: initialized
00:50:23 3 EURUSDm,M5: A::A()
00:50:23 3 EURUSDm,M5: uninit reason 0
00:50:23 Script 3 EURUSDm,M5: removed

¿Por qué todo está bien cuando un objeto se crea dinámicamente, es decir, el constructor privado está disponible desde el método del objeto, pero cuando el objeto se crea automáticamente, el constructor privado de repente no está disponible?

Personalmente, he renunciado a hacer algo más complicado que lo simple en MQL, porque me resulta muy difícil: siempre me encuentro con algo que no funciona.

Pero no tengo esos problemas con los compiladores de C/C++.

Y el problema "es razonable no controlarme, que el control sea separado nunca ejecutar utilidades" está directamente relacionado con la psicología. Aquí hay que corregir la psicología para que el programador se obligue a sí mismo, en lugar de intentar ajustar la tecnología a la psicología para sortear esta psicología.

No me lo invento, algunas utilidades se utilizan con éxito de forma habitual delante de mí, y el resultado de su trabajo también se utiliza con éxito más tarde para eliminar fallos.

Renat:

Se están combatiendo los fallos, pero paralelamente estamos añadiendo y mejorando mucho.

Tal vez las prioridades se desplacen hacia la adición y la mejora en detrimento de la calidad. Pero entonces ya no es un control total de la misma.

Renat:

El viernes habrá un lanzamiento de MT4 con claras mejoras en la velocidad de ejecución y en las pruebas.

En este caso me refiero a la disponibilidad de constructores privados a partir de los métodos de los objetos, no sólo para el caso de la creación de objetos dinámicos - ¿habrá alguna mejora en la operatividad del lenguaje?

Renat:

A diferencia de C++, MQL es absolutamente seguro (si no hay salida a la dll) debido al rechazo de los enlaces crudos, y en general - es un lenguaje administrado.

Bien, asumamos que "C++ es peligroso y suicida" y "MQL es absolutamente seguro".

¿Por qué tomar como base de MQL un lenguaje que está tan lejos del criterio de seguridad de lo que se quería, es decir, crear un lenguaje "absolutamente seguro" basado exactamente en el "peligroso y suicida"?

 
Pavlick:

¿DE ACUERDO?


¡Hola, Pavlik!

¡soy yo otra vez panza!

He estado probando su código para llamar a la secuencia de comandos en diferentes mt4

¡y descubrí algunas cosas extrañas!

Su código funciona bien en MT4 build 670 de Pepperston

¡(Australia), pero no quiere trabajar en MT4 build 670 Alpari!

¡user32.dll sellamaextrañamenteen alpari!

Se llaman las 2 primeras dlls (¡aunque esto no estaba en el código!)

entonces se llama auser32.dll,¡pero se lanza a una biblioteca!

pero también hay que llamarlo desde la biblioteca.

Parece que Alpari está luchando con la llamada.

es decir, ¡hay una evidente interferencia de código!

Adjunto 2 fotos para comparar.

¡Deseo que tenga éxito!

Panza

¡oo-bild zu gross!

MT4-Pepperstone-user32.dll

MT4-Alpari-KERNEL32.dll,GDI.dll,E:\NmetaQuotes\Terminal\F................OBO\MQL4\Libraries\user32.dll

















 
simpleton:

"Qué tontería" - esto aparentemente significa un completo desajuste de posiciones.

Esto significa que alguien tiene más experiencia, a sabiendas, en la dirección del lanzamiento de múltiples productos de software a un mercado competitivo.


¿Por qué el "control de calidad total" permite un nivel de control de calidad tan bajo?

No es necesario pasar de un debate sobre los principios generales de control de calidad a las deficiencias específicas de una solución concreta. Este método es inaceptable, porque siempre es posible encontrar cualquier defecto en cualquier producto.

Por ejemplo:

El constructor es llamado cuando se crea un objeto en el método2:

¿Por qué todo está bien cuando un objeto se crea dinámicamente, es decir, private-constructor está disponible desde el método del objeto, pero cuando un objeto se crea automáticamente, private-constructor de repente no está disponible?

Esto es sólo una consecuencia de la sobreprotección"el método de la claseestática no tiene derecho a entrar en el contenido de la clase". En este caso, sin embargo, hay que aflojar el control de acceso.

Personalmente he renunciado a hacer cualquier cosa un poco más compleja que simple en MQL, porque me resulta muy difícil: siempre me encuentro con algo que no funciona.

Dame un ejemplo que funcione, no un caso de "torcí las cosas a propósito, cerré los accesos y luego empecé a apelar a un comportamiento al límite".


Sin embargo, no tengo esos problemas con los compiladores de C/C++.

Los problemas allí son de otro tipo. Y son conscientemente mayores en órdenes de magnitud si se tiene en cuenta que no se utilizan analizadores estáticos.


Y el problema "es razonable no controlarme, que el control sea separado nunca ejecutar utilidades" está directamente relacionado con la psicología. Aquí hay que corregir la psicología para que el programador se obligue a sí mismo, en lugar de intentar ajustar la tecnología a la psicología para sortear esta psicología.

No me lo invento, las utilidades individuales se utilizan con éxito de forma regular ante mis ojos, y el resultado de su trabajo también se utiliza con éxito después para eliminar los errores.

Tal vez las prioridades se desplacen hacia la adición y la mejora en detrimento de la calidad. Pero entonces ya no es un control total de la misma.

Ya es sólo un juego de palabras. Su posición ya ha sido claramente esbozada anteriormente "no puedo ser controlado", así que sí "frente a alguien, en algún lugar está consumiendo, pero nadie está parado sobre mí con un palo y no estoy consumiendo".


Y las mejoras en cuanto a la operatividad del lenguaje -en este caso me refiero a la disponibilidad de constructores privados a partir de métodos de objetos no sólo para el caso de la creación de objetos dinámicos- ¿ya las tendrá?

¿Y te gusta hacer zancadillas deliberadas en tus programas "simples": "Voy a ocultar el constructor en privado, crear un método estático y luego usarlo para cincelar el constructor oculto"?


Bien, asumamos que "C++ es peligroso y suicida" y "MQL es absolutamente seguro".

¿Por qué tomar una lengua tan alejada del criterio de seguridad como base de la MQL, es decir, crear una lengua "absolutamente segura" sobre la base de la muy "peligrosa y suicida"?

¿Es usted capaz de dar una "base diferente" para un lenguaje genérico?

¿Para que cualquier otro programador pueda recibir el lenguaje y empezar a escribir en él con gusto después de un par de horas y no tirarlo con disgusto y regañina? Los operadores han mirado el Lenguaje Fácil y lo han desechado, mientras que MQL4/MQL5 se están utilizando y desarrollando con mucho gusto.

Los lenguajes más utilizados se basan en los principios básicos de las construcciones como en C/C++. Así que tomamos el marco conocido, eliminamos las cosas más peligrosas con enlaces, añadimos DRM y recibimos un lenguaje seguro y protegido.

Como resultado, estamos en alza y los competidores van en direcciones equivocadas, pero más baratas, como ellos creen.

 
Renat:
Significa que alguien tiene más experiencia en la gestión del lanzamiento de muchos productos de software en un mercado competitivo.

Por cierto, sobre la experiencia de gestión. Hace 5 años discutimos en el foro de mql5 sobre las perspectivas de MT5, yo dije entonces que el tiempo lo dirá. Han pasado cinco años y vemos que la comunidad ha rechazado MT5. La experiencia en la gestión no garantiza que no se cometan errores. Aunque uno tenga experiencia en un área, puede cometer errores. Sobre el tema del mercado competitivo, o más bien de los competidores, al final.

Sin embargo, en este caso, no se trata de la experiencia en muchos productos de software, sino de la calidad del producto y, en particular, del compilador y de las herramientas y métodos para lograr una alta calidad.

Renat:
No debemos trasladar la discusión de los principios generales de control de calidad a los defectos específicos de una solución concreta. No se puede hacer esto porque siempre es probable que se encuentren todos los defectos en cada producto.


Esto es sólo una consecuencia de la sobreprotección "el método de la clase estática no tiene derecho a entrar en el contenido de la clase". Aunque en este caso hay que aflojar el control de acceso.

No estoy traduciendo, principios generales, teoría - no para la teoría en sí, sino para la aplicación en la práctica. No encontrarás "defectos" tan graves en los mismos compiladores de C/C++.

Si dices que en este caso "un método de una clase estática no tiene derecho a entrar en el contenido de la clase", entonces ¿por qué en el caso de la creación de objetos dinámicos ya tiene este derecho?

¿Qué pasa con el hecho de que un método no estático se comporta exactamente igual?

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }
  ~A() { Print("A::~A()"); }

public:
  void method() { // Метод - обычный, никакой не статический
    A a;
  }

};

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

Los mismos errores:

'3.mq4' 3.mq4   1       1
'A::~A' - cannot call private member function   3.mq4   11      7
'A::A' - cannot call private member function    3.mq4   11      7
2 error(s), 0 warning(s)                3       1

Bien, consideremos la prohibición de "subir al contenido de la clase":

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }
  ~A() { Print("A::~A()"); }
  A(const A &a) { Print("A::A(const A &)"); }
  void operator =(const A &a) { Print("A::operator =()"); }
  void f() { Print("A::f()"); }

public:
  static void assign(A &l, const A &r) {
    l = r;
  }

  static void method() {
    A *p = new A, b(p);

    b = p;
    b.f();
    delete p;
  }

};

El objeto b se crea llamando al constructor copy, luego se realiza una asignación llamando al "operador =", se llama al método f(), y todos estos constructores, operadores y métodos son privados, lo que significa que el método estático method() puede "acariciar la clase":

00:59:18 Script 3 EURUSDm,M5: loaded successfully
00:59:18 3 EURUSDm,M5: initialized
00:59:18 3 EURUSDm,M5: A::A()
00:59:18 3 EURUSDm,M5: A::A(const A &)
00:59:18 3 EURUSDm,M5: A::operator =()
00:59:18 3 EURUSDm,M5: A::f()
00:59:18 3 EURUSDm,M5: A::~A()
00:59:18 3 EURUSDm,M5: A::~A()
00:59:18 3 EURUSDm,M5: uninit reason 0
00:59:18 Script 3 EURUSDm,M5: removed

Veamos otro ejemplo, muy cercano al primero:

#property strict

/******************************************************************************/
class A {
private:
  A(int i = 0) { Print("A::A(int i = ", i, ")"); }
  ~A() { Print("A::~A()"); }
public:

  static void method() {
    A a;
  }
};

/******************************************************************************/
void OnStart() {
  A::method();
}

Error de compilación, - tanto el constructor como el destructor no están disponibles:

'3.mq4' 3.mq4   1       1
'A::~A' - cannot call private member function   3.mq4   11      7
'A::A' - cannot call private member function    3.mq4   11      7
2 error(s), 0 warning(s)                3       1

Ahora, sin cambiar nada en absoluto, inicializa la variable a con un valor diferente al valor por defecto en el constructor:

#property strict

/******************************************************************************/
class A {
private:
  A(int i = 0) { Print("A::A(int i = ", i, ")"); }
  ~A() { Print("A::~A()"); }
public:

  static void method() {
    A a(1);
  }
};

/******************************************************************************/
void OnStart() {
  A::method();
}

Ahora el ejemplo se compila y ejecuta:

00:20:35 Script 3 EURUSDm,M5: loaded successfully
00:20:35 3 EURUSDm,M5: initialized
00:20:35 3 EURUSDm,M5: A::A(int i = 1)
00:20:35 3 EURUSDm,M5: A::~A()
00:20:35 3 EURUSDm,M5: uninit reason 0
00:20:35 Script 3 EURUSDm,M5: removed

¿Cómo es que de repente un método estático puede "entrar en el contenido de la clase"?

Es bastante obvio que no se trata de una "sobreprotección" en este caso, sino de un error trivial. El control de calidad total es una afirmación bastante ruidosa, pero los hechos son algo obstinado.

Renat:
Poner un ejemplo de trabajo, no un caso de "he torcido las cosas a propósito, he cerrado los accesos y luego he empezado a apelar al comportamiento de los límites".

Por favor, un singleton clásico, concretamente el singleton de Myers descrito en la sección de ejemplos de C++ del enlace:

class OnlyOne
{
public:
        static const OnlyOne& Instance()
        {
                static OnlyOne theSingleInstance;
                return theSingleInstance;
        }
private:        
        OnlyOne(){};
        OnlyOne(const OnlyOne& root);
        OnlyOne& operator=(const OnlyOne&);
};

Incluso se traduce en MQL4++ con la nueva función abierta:

#property strict

/******************************************************************************/
class OnlyOne
{
public:
        static OnlyOne *Instance()
        {
                static OnlyOne theSingleInstance(1);
                return GetPointer(theSingleInstance);
        }
private:        
        OnlyOne(int i = 0) { Print("Создан"); };
        ~OnlyOne() { Print("Уничтожен"); };
        OnlyOne(const OnlyOne &);
        void operator=(const OnlyOne &);
};

/******************************************************************************/
void OnStart() {
  OnlyOne *p = OnlyOne::Instance();
}

Compila y ejecuta:

01:31:49 Script 3 EURUSDm,M5: loaded successfully
01:31:49 3 EURUSDm,M5: Создан
01:31:49 3 EURUSDm,M5: initialized
01:31:49 3 EURUSDm,M5: uninit reason 0
01:31:49 3 EURUSDm,M5: Уничтожен
01:31:49 Script 3 EURUSDm,M5: removed

Los intentos de crear un objeto de cualquier manera que no sea llamando a OnlyOne::Instance() resultarán en un error de compilación.

Y sobre el tema de "torcí las cosas tan deliberadamente, cerré los accesos y luego empecé a apelar al comportamiento de los límites", ¿se utilizó algo indebidamente?

Hay mecanismos en la lengua: tengo derecho a utilizarla como quiera dentro de los límites que permite la lengua. Al menos así es con los compiladores de C++.

Si hay errores en la implementación del lenguaje, pues sí, errores. Usted está hablando de control de calidad total - por lo que en la práctica deshacerse de los errores de implementación en MQL4 ++ compilador, por lo que los errores son casi tan difícil de encontrar como en los compiladores de C ++, ya que tiene tal control. Sigo creyendo que el analizador sintáctico no ayudará a eliminar errores como los que he demostrado.

Renat:
¿Y te gusta poner pasos deliberados en tus programas "simples" "ocultar el constructor en privado, crear un método estático y luego cincelar en constructor oculto desde él"?

No se trata de lo que me gusta o no me gusta. Hay una herramienta. ¿Por qué debería negarme a utilizar todas sus capacidades?

En este caso ni siquiera es "me gusta". Es Myers, para el caso, a quien le gusta tanto. Y, de alguna manera, nadie trata de acusarle de intentar "poner deliberadamente la zancadilla" a los compiladores de C++.

Renat:
¿Es usted capaz de idear un "marco diferente" para los lenguajes genéricos?

¿Para que cualquier otro programador pueda recibir un lenguaje y empezar a escribir en él con gusto después de un par de horas y no tirarlo con asco y regañina? Los operadores han mirado el Lenguaje Fácil y lo han desechado, mientras que MQL4/MQL5 se utilizan y desarrollan felizmente.

Los lenguajes más extendidos se basan en los principios básicos de las construcciones como en C/C++. Así que hemos tomado un marco familiar, hemos eliminado las cosas más peligrosas con referencias, hemos añadido DRM y hemos conseguido un lenguaje seguro y protegido.

Como resultado, estamos en la cima, mientras que los competidores van en la dirección equivocada, pero más barata, como ellos piensan.

No es una tarea fácil y no puede resolverse de buenas a primeras. Aquí hay que esforzarse, y mucho. La gran mayoría de los usuarios de MQL no son programadores. Esto debe tenerse en cuenta en el diseño del lenguaje. Pero la tarea puede resolverse, estoy seguro.

Si acaso, bastaría con añadir algunas estructuras al viejo MQL4 y limpiar algunas cosas como las prioridades a las operaciones, como se hizo para MQL4++ y eso sería un compromiso razonable. El éxito de MT4 se debió en gran medida a la ausencia de "ingenio" del lenguaje. Este no es el caso ahora. Y hay muchos más errores en la implementación del compilador, porque MQL4++ es mucho más complicado que el antiguo MQL4 y el equipo de desarrollo apenas ha cambiado.

Renat:
En consecuencia, estamos al alza, mientras que nuestros competidores van en la dirección equivocada, pero más barata, como ellos creen.

Aquí estoy de acuerdo contigo, pero creo que es principalmente porque los competidores están haciendo cosas incomprensibles.

 
Renat:
Esto significa que alguien tiene más experiencia a sabiendas en la dirección del lanzamiento de muchos productos de software al mercado de la competencia.


No hace falta que pasemos de discutir los principios generales de control de calidad a los defectos específicos de una solución concreta. Este método es inaceptable, porque siempre es posible encontrar cualquier defecto en cualquier producto.

Esto es sólo una consecuencia de la sobreprotección "un método de clase estática no tiene derecho a entrar en el contenido de la clase". Aunque en este caso hay que aflojar el control de acceso.

Danos un ejemplo que funcione, no un caso del tipo "lo torcí todo a propósito, bloqueé los accesos y luego apelé al comportamiento de los límites".


Los problemas allí son de otro tipo. Y son conscientemente mayores en órdenes de magnitud si se tiene en cuenta que no se utilizan analizadores estáticos.


Esto ya es un juego de palabras. Tu posición ya ha sido claramente esbozada anteriormente "no puedo ser controlado", así que sí "frente a alguien, en algún lugar consumiendo, pero nadie está parado sobre mí con un palo y no estoy consumiendo".


¿Te gusta poner pasos deliberados en tus programas "simples" "ocultar el constructor en privado, crear un método estático y luego cincelar en constructor oculto desde él"?


¿Es capaz de dar una "base diferente" a las lenguas de commonplan?

¿Para que cualquier otro programador pueda recibir un lenguaje y empezar a escribir en él con gusto después de un par de horas y no tirarlo con disgusto y regañina? Los operadores han mirado el Lenguaje Fácil y lo han desechado, mientras que MQL4/MQL5 se utilizan y desarrollan felizmente.

Los lenguajes más extendidos se basan en los principios básicos de construcción como en C/C++. Así que tomamos el marco conocido, eliminamos las cosas más peligrosas con enlaces, añadimos DRM y conseguimos un lenguaje seguro y protegido.

Como resultado, estamos en la cima, mientras que nuestros competidores van en la dirección equivocada, pero más barata, como ellos piensan.

 

¡Hola miembros del foro!

Me gustaría aprovechar la presencia de Renate en este hilo

¡Me gustaría hacer algunas sugerencias para mejorar MT4!

Todo el mundo sabe que con el tiempo MT4 funciona cada vez peor.

entonces no obedece al ratón - ¡finito!

Tenemos que pasar a una nueva MT4 y eliminar

¡todo el material (indicadores, eXpertos)!

¡Esto es un trabajo de un día!

Aunque ahora hay programas de reparación de DLL, Drever y otros...

¿Por qué no hacer un compilador para MT4?

Tienes que tener 2 МТ4 (uno válido y otro que funcione)

y compararlos periódicamente y corregir los errores en el MT4 de trabajo.

La segunda sugerencia es construir no sólo gráficos de precios sino

¡producir gráficos de crecimiento del precio multiplicado por el volumen!

de esta manera usted sería inmediatamente visible lo que está sucediendo (comercio real o cobro

paradas)

¡creo que es fácil para las personas con alto nivel de comprensión!

Panza

1...45678910111213141516
Nuevo comentario
Razón de la queja: