Errores, fallos, preguntas - página 2724
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
No. Hay que hacer FileFlush si se quiere que otra persona pueda leer el archivo modificado
El problema es que el programa MQL5 lee el archivo en su propio buffer al abrirlo. Y no sabe nada de lo que ha cambiado en el archivo hasta que lo vuelve a leer. El archivo sólo se puede volver a leer cerrando y abriendo ese archivo
Glory, ese es exactamente el problema. Por favor, echa un vistazo al enlace que pongo arriba, encontrarás el código para reproducirlo.
El mismo archivo se abre desde el mismo EA, 1 descriptor para la escritura, el segundo para la lectura, fileflush se utiliza después de la escritura, intente la lectura, y no funciona correctamente.
Por supuesto, si se cierra/abre funciona, pero entonces no es necesario usar FileFlush.
Gloria, este es exactamente el problema. Por favor, echa un vistazo al enlace que publico arriba, encontrarás el código para reproducirlo.
El mismo archivo se abre desde el mismo asesor, 1 descriptor para la escritura, el segundo para la lectura, fileflush se utiliza después de la escritura, intente la lectura, y no funciona correctamente.
Por supuesto que si se cierra/abre funciona, pero entonces no es necesario usar FileFlush.
Entiendo el problema que describes.
El 1er EA escribe el archivo. Puede que no cierre ese archivo, pero en ese caso debería llamar a FileFlush
El 2º Asesor Experto lee el archivo. Debería abrir el archivo cada vez y luego cerrarlo.
¡Abrir y cerrar el archivo sólo para el segundo EA!
A eso me refiero exactamente. Cerrar y volver a abrir
¿O se refiere a FileFlush antes de cerrar el archivo?
Sí, ¿es necesario enjuagar antes de cerrar? O el cierre de la misma garantiza la relevancia del archivo grabado.
Sí, ¿es necesario enjuagar antes de cerrar? O bien, el cierre garantiza que el archivo registrado esté actualizado.
Entiendo el problema que describes.
El 1er EA escribe el archivo. Puede que no cierre el archivo, pero en este caso debería llamar a FileFlush
El 2º Asesor Experto lee el archivo. Tiene que abrir el archivo cada vez y luego cerrarlo.
¡Abrir y cerrar el archivo sólo para el segundo EA!
Entiendo que se trata de una solución.
Pero sería mejor corregir el error, no es posible fácilmente, supongo.
Sí, ¿es necesario enjuagar antes de cerrar? O bien, el cierre garantiza que el archivo registrado esté actualizado.
No necesariamente. Los búferes se restablecen automáticamente si no se ha hecho una llamada a FileFlush antes de cerrar
Bug MT5 (build 2390) cuenta incorrectamente las llaves en la descripción de la estructura de la clase.
Un Asesor Experto que lee un archivo debe mantener este archivo cerrado.
La peculiaridad de la implementación de los archivos en MQL5 es que mantienen los datos de los archivos en sus propios buffers tanto como sea posible. Si el tamaño de la información es tan grande que no cabe en el buffer, tu truco de mover el puntero al principio y luego al final del archivo puede funcionar.
Así que de momento abre el archivo, comprueba el contenido y vuelve a cerrarlo
Como dije arriba (en su propio texto), es viceversa en mi caso de prueba - el indicador lee, el Asesor Experto escribe. Pero, por lo que tengo entendido, el tipo de programa no es importante. El problema es arquitectónico.
La implementación del archivo especificado en MQL5 es un error. Cerrar y abrir un archivo es una solución, pero no debería ser así para leer un archivo compartido.
Cuidar la optimización del rendimiento es bueno, pero no debe afectar negativamente a la funcionalidad.
PS. Como solución rápida y sucia, he aquí una sugerencia: en respuesta a una llamada de FileFlush para un archivo abierto para la lectura - actualizar su buffer.
Probablemente porque µl C++ es similar, y las estructuras llegaron allí desde C.
Si necesitas constructores, utiliza clases o da la bienvenida a Sharp. ¿Por qué hay que privar a las estructuras de esta connotación? Esto sólo hará que los programas sean más expresivos. Puedo tomar el código de alguien y ver que tiene una estructura en lugar de una clase y obtener mucha información de una sola palabra. No conseguirás nada, estudiarás diligentemente el código fuente para obtener el mismo resultado, que yo conseguí en un abrir y cerrar de ojos. En mi experiencia - esta convención de estructuras se respeta, bueno, tal vez algún tipo de viento marginalismo nihilista.
Pero en C++ las estructuras y las clases son una misma cosa. Por eso, todos tus razonamientos sobre la "expresividad del código" no afectan a la esencia de las cosas.También puedes definir cualquier otra palabra expresiva excepto struct o class a través de un define y no cambiará nada (me refiero a C++).
Por eso debemos hablar de las estructuras sólo desde el punto de vista de C#, de donde se toma su concepto. Las estructuras son tipos de valor, por lo que son mucho más compactas que las clases, no son polimórficas y no pueden ser referenciadas, esto último es especialmente importante.
No hay maldad allí, te parece. Incluso hay un estándar extendido: la lectura de unsigned char y std::byte sin inicializar no es un comportamiento indefinido. Puede utilizar la inicialización agregada para POD. Y no olvides que toda esta inicialización no es gratuita, es un consumo real de recursos (CPU, memoria, tamaño de un ejecutable). Si te importa un carajo con tu máquina de hacer números, en el caso de algún microcontrolador puede ser importante. Después de todo, C/C++ no es sólo un factor de forma de Windows como Sharp.
La inicialización de una sola variable aumentó el tamaño de la instrucción en un 30%.
Nadie dice que la inicialización sea gratuita por sí misma, pero uno la necesitaría de todos modos, así que no entiendo muy bien el significado de tus mediciones con y sin inicialización.
Otra cosa es que el compilador no reinicie las variables:
Así que toda esa paranoia de tener miedo a la preinicialización de variables es ridícula. Esto es el año 2020, sobre todo si se habla de estructuras POD, cuya inicialización seguro que está optimizada por el compilador.
La ausencia de preinicialización es aceptable sólo cuando existe un control del 100% del compilador que prohíbe la lectura de variables no inicializadas.
En C++, las estructuras y las clases son una misma cosa. Así que todos tus argumentos sobre la "expresividad del código" no afectan a la esencia de las cosas.También puedes definir cualquier otra palabra expresiva que no sea struct o class a través de una definición y no cambiará (me refiero a C++)
Que persona más testaruda ))), a ti te pasa lo mismo, no necesitas definir nada con una definición, ya hay una palabra - struct. Puedes ignorarlo, pero entonces no te sorprendas de que los codificadores decentes te miren como un codificador de mierda cuando vean tus estructuras rellenas de funciones. Quizás fue un error en los albores de los cruces equiparar estructuras y clases, debería haber dejado las estructuras como en C.
Por eso debemos hablar de las estructuras sólo desde el punto de vista de C#. De ahí se toma su concepto. Las estructuras son tipos-valor, por lo que son mucho más compactas que las clases, no son polimórficas y no pueden ser referenciadas. Esto último es especialmente importante.
¿Cree que su Sharp apareció en un campo limpio? Con raíces en C, la estructura es un contenedor mudo sin azúcar adicional.
Otra cosa es que el compilador no reinicie las variables:
Así que toda esa paranoia de tener miedo a la preinicialización de variables es ridícula. Estamos en el año 2020, sobre todo si se trata de estructuras POD, cuya inicialización seguramente será optimizada por el compilador.