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

[Andrei01]

simpleton:

Las variables locales y los parámetros están en el mismo ámbito, así que - no importa si un parámetro tiene este nombre o una variable local, pero de cualquier manera este nombre oculta el nombre en el ámbito externo.

No en cualquier caso. Cuando se pasa una variable por referencia, no se crea una copia local y se trabaja directamente con la variable pasada. ¿Qué tipo de ocultación hay aquí?

[[Eliminado]]

Andrei01:
No en ninguna función. Cuando se pasa una variable por referencia, no se crea una copia local y la operación se realiza directamente con la variable pasada. ¿Qué tipo de ocultación hay aquí?

Aquí es donde tiene lugar la ocultación de nombres. Todo lo demás -copiar, no copiar- es secundario. Dentro de una función, cuando se utiliza un nombre de referencia, el trabajo se realizará sobre el objeto al que se refiere la referencia. Si se refiere a un objeto en el ámbito externo, el trabajo se hará con él. Esto no se debe a que no haya ocultación de nombres -la ocultación está presente, al igual que en otros casos- sino a que la referencia apunta a este objeto. Una función se llama así. Pasó este mismo objeto por referencia y ahora apunta a él. Al llamar y pasar al momento de llamar a otro objeto, el mismo código de la función funcionará con otro objeto.

Ponía un ejemplo con un nombre de tipo y un nombre de variable, es decir, con entidades de naturaleza lo más diferente posible, para mostrar que la ocultación se aplica/referencia a los nombres, y todo lo demás es secundario.

Sin embargo, al intentar crear otro ejemplo en MQL4++ sobre este tema, descubrí accidentalmente que se crea un ámbito adicional para los parámetros en MQL4++. El ámbito de las variables locales ya está anidado en él:

#property strict

void f(int a) {
  int saved = a;
  int a = a + 1;

  Print("saved = " , saved, ", a = ", a);
}

void OnStart() {
  f(3);
}

Este ejemplo está compilado con una advertencia característica:

declaration of 'a' hides local declaration at line 3    3.mq4   5       7

Y posteriormente se ejecuta con éxito:

23:52:22 Script 3 EURUSDm,H1: loaded successfully
23:52:22 3 EURUSDm,H1: initialized
23:52:22 3 EURUSDm,H1: saved = 3, a = 4
23:52:22 3 EURUSDm,H1: uninit reason 0
23:52:22 Script 3 EURUSDm,H1: removed

Es obvio que se crea otro ámbito de "capa" para los parámetros en MQL4++. Por eso es posible declarar una variable local con el mismo nombre que el parámetro.

En C/C++ no existe esa "capa":

void f(int a) {
  int saved = a;
  int a = a + 1;
}

El compilador explica popularmente que ya existe una variable con ese nombre en el ámbito:

$ icpc -c 1.cpp
1.cpp(3): error: "a" has already been declared in the current scope
    int a = a + 1;
        ^

Es decir, el ámbito de los parámetros de la función y sus variables locales son uno y el mismo.

Por qué no es así en MQL4++ y para qué no lo es - es, por supuesto, una pregunta interesante...

[Andrei01]

simpleton:

void f(int a)

Este ejemplo COMPILA con un aviso característico:

Este caso discute el caso de pasar una variable por referencia y una advertencia errónea, no la creación de una copia local.

void f(int& a)

[[Eliminado]]

Sólo he leído los primeros posts.

Por supuesto, las cosas tampoco van del todo bien bajo la alfombra. Aquí hay algunos fallos de los desarrolladores a la hora de probar el producto que llega al usuario final. Sin embargo, también MT4 no es fuerte en las estrategias multidivisas (pruebas), y necesita, necesita ser refinado. Así que espero que sea algún día, después de todo.

Si no sabes programar, no vayas a la real, y usa la demo por ahora. Como siempre un mal bailarín se interpone en el camino de los "balones", incluido el dorado y el rosa.

Buena suerte.

[[Eliminado]]

Andrei01:

Este es un caso de pasar una variable por referencia y una advertencia errónea, no de crear una copia local.

void f(int& a)

Realmente no importa la naturaleza de la advertencia. Además, no sólo importa si una variable se pasa por referencia o por valor, sino de qué tipo es:

#property strict

int a; // line 3
class A { };
void f(A *&a) { } // line 5
void OnStart() { }

El código se compila y se genera la advertencia que comentas:

declaration of 'a' hides global declaration at line 3   3.mq4   5       12

Por alguna razón no quieres entender eso.

La advertencia en sí no es en absoluto errónea. Además, a simple vista, el seguimiento del alcance en MQL4++ está sorprendentemente bien hecho en comparación con cómo se hacen otras cosas.

Las advertencias, si bien son ciertas, no son prácticas y, sin embargo, no puedes desactivarlas, de eso se trata. Y en absoluto sobre la transmisión en el enlace.

[Andrei01]

simpleton:

En cuanto a la naturaleza de la advertencia, esto es irrelevante. Además, no importa si la variable se pasa por referencia o por valor

Hay una gran diferencia en la esencia de la advertencia entre pasar la propia variable y modificarla en una función y crear una copia de la misma, mientras que la propia variable permanece inalterada.

Y el hecho de que las advertencias no se pueden desactivar o personalizar, es un clásico estilo propietario de MC - "no dejar":))) No hay nada que puedas hacer al respecto, pero sólo puedes aceptarlo humilde y mansamente porque este estilo ha sido elevado a la categoría de atributo religioso... No tiene sentido buscar la lógica ni ningún tipo de justicia en este caso. ))

[Debugger]

Ugh ugh tengo todas las cosas de methaquot funcionando como un reloj.

No hay ninguna queja.

[Vasiliy Sokolov]

simpleton:

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 errónea, porque pueden NO ser errores en absoluto.

...

Esta gente es un friki. Estos idiotas luchan contra el compilador como si fuera un molino de viento sin entender lo principal: ¡el compilador es tu aliado! Alégrese cuando el compilador jure fragmentos de código potencialmente inseguros. Alégrate incluso si la aplicación se bloquea justo después del lanzamiento con una cadena de error. Pero Dios no quiera que tengas un código inmanejable cuando no hay errores ni advertencias y el programa parece funcionar bien pero de vez en cuando se producen extraños fallos cuya causa no se puede rastrear en ninguna parte. En esos momentos te cubres de vapor y empiezas a soñar con errores como"puntero no válido" o "división por cero".

[Andrei01]

C-4:
Pero Dios no quiera que tengas un código inmanejable cuando no hay errores ni advertencias y el programa parece funcionar bien pero de vez en cuando se producen extraños fallos cuya razón no se encuentra en ningún sitio. En esos momentos te cubres de vapor y empiezas a soñar con errores como "puntero no válido" o "división por cero".

El compilador no tiene nada que ver, es la típica escritura con errores cuando no hay comprobaciones de prueba en fragmentos de código peligrosos en los que son posibles estados indefinidos o erróneos, por eso aparecen los fallos.

Las comprobaciones de código funcional no tienen nada que ver con el compilador y no tiene sentido esperar eso desde el principio.

De nuevo, los programadores profesionales no suelen mirar las advertencias porque conocen la lógica del compilador, mientras que los compiladores son inútiles para comprobar la funcionalidad del código.

[[Eliminado]]

Andrei01:

Hay una gran diferencia en las advertencias de esencia entre pasar la variable en sí y modificarla en una función y hacer una copia de la misma, mientras que la variable en sí permanece sin cambios.

Aquí es sólo un tipo diferente de advertencia. Sobre la ocultación de nombres.

La variable en sí no se pasa. Se pasa una referencia a ella.