La diferencia entre externo y de entrada - página 5
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Imagina que estas inicializaciones se realizan en diferentes archivos de inclusión. Entonces, el resultado final dependerá del orden en que se incluyan estos archivos.
Bueno - incluso los errores tan obvios con estos externos
Así que estoy escribiendo que no tienen sentido, son sólo para la compatibilidad con el código antiguo - reemplazar extern con la entrada y corregir los errores ... propósito poco claro.... extern no tiene sentido - búsquelo
Desgraciadamente, la implementación de las variables externas en MQL5 no está finalizada, y es por eso que no recomiendo su uso - podría causar problemas. Me refiero a la falta de control sobre la inicialización obligatoria de una sola vez de estas variables.
Por ejemplo, puede escribirlo de esta manera:
y no habrá ningún error. Imagina que estas inicializaciones se realizan en diferentes plugins. Entonces, el resultado final dependerá del orden en que se incluyan estos archivos.
O podemos escribirlo así (archivo ejecutable):
aquí no hemos inicializado la variable externa en absoluto, pero tampoco hay error.
En consecuencia, no se puede controlar si las mismas variables están definidas en otros archivos o no. Se puede cambiar accidentalmente su nombre, pero el programa compilará como si no hubiera pasado nada, aunque en otros archivos tengamos una variable con un nombre diferente.
En definitiva, no cabe en ningún sitio. Por eso es mejor utilizar funciones en lugar de variables externas, ya que se garantiza que sólo tienen una definición, ni más ni menos.
Con este enfoque, no deberías usar un ordenador en absoluto. Porque si cierras los ojos y atizas el teclado, obtendrás tonterías.
El verdadero problema en extern se produce cuando se intenta hacer extern desde la entrada. No recuerdo los detalles, sucedió hace mucho tiempo. Como resultado, rechacé extern en absoluto, declaré una simple variable en el archivo include y establecí su valor en el EA inite a través de una llamada a la función.
ahí lo tienes - incluso los errores tan obvios con estos externos
Por eso escribo que no tienen sentido, son sólo para compatibilidad con códigos antiguos - sustituye extern por input y corrige los errores... de lo contrario la ayuda dice... propósito poco claro.... externa no tiene sentido, por mucho que se busque.
Hay un sentido. En MT5 en los archivos incluidos no se introduce extern en absoluto.
Tiene sentido. En MT5, extern en los archivos de inclusión no es una entrada en absoluto.
¿Por qué se añaden los externos a los archivos de inclusión?
No sé qué está pasando en el mundo moderno de la escritura de programas, pero yo aprendí a escribir en estilo procedimental, y luego empecé a usar OOP. El primer y el segundo estilo implican que cada unidad lógica debe ser completamente funcional cuando se transfiere a otro programa, es decir, se escribe una función - su descripción (cabecera) contiene todos los parámetros que utiliza - no necesita iprouts - cortas y pegas esta función en otro archivo, se "movió" tal cual - lo mismo con las clases.
Y los propios iprouts sólo deberían crear la interfaz de usuario, siempre deberían estar descritos en el archivo principal.
Y el uso de extern en el archivo de inclusión, imho manera de conseguir difícil de rastrear el error,@Alexey Navoykov arriba mostró cómo sucede, por desgracia, más de la mitad de los nombres de las variables de todos los programadores tienen a una letra el mismo nombre, la diferencia máxima en el uso de mayúsculas / minúsculas, como un ejemplo MagicNumber o Magia - si se mira KB, a continuación, cada otra variable, por lo que en su método es una amenaza para "sombra" extern en su variable, afortunadamente pocas personas ahora utilizan ecterps
¿por qué añadir iprtu's en los archivos de inclusión?
No sé lo que está pasando en el mundo moderno de la escritura de programas, pero aprendí a escribir en el estilo de procedimiento, a continuación, comenzó a utilizar OOP, tanto en el primer y en el segundo estilo se implica que cada unidad lógica debe ser totalmente funcional cuando se transfiere a otro programa, es decir, escribió una función - en su descripción (en el título) tienen todos los parámetros que utiliza - no necesita iprouts - cortar esta función y se inserta en otro archivo, que "se trasladó" como es - lo mismo con las clases.
Y los iprouts en sí sólo deben crear la interfaz de usuario, siempre deben ser descritos en el archivo principal.
No es así. En los archivos de inclusión agrega los externos. Para que en los archivos de inclusión se puedan utilizar las entradas declaradas en el archivo principal.
Por cierto, casi siempre se necesita en cuanto se empiezan a utilizar los archivos de inclusión.
No así. Añadir externos a los archivos de inclusión. Para que en el archivo de inclusión pueda utilizar las entradas declaradas en el archivo principal.
Por cierto, esto es lo que necesitas casi desde que empiezas a utilizar los archivos de inclusión.
dar un ejemplo de por qué se debe utilizar extern
dar un ejemplo de la conveniencia de utilizar extern
Hace tiempo que existe.
No deberías usar un ordenador en absoluto si adoptas este enfoque. Porque si cierras los ojos y picas el teclado, te sale una mierda.
Hace tiempo que está aquí.
A eso me refiero.
Su ejemplo es la generación de errores ocultos, el nombre de la variable x se utiliza a menudo.... escribió arriba
En mi opinión, debería ser así:
A eso me refiero.
Su ejemplo es la aparición de bichos ocultos, el nombre de la variable x se utiliza a menudo.... escribió arriba
En mi opinión, debería ser así:
De ninguna manera. La variable x debe estar disponible no sólo en una función, sino en todas las funciones. Y aún más: debe estar disponible en el archivo principal, así como en todos los archivos conectados.