Errores, fallos, preguntas - página 1576
![MQL5 - Lenguaje de estrategias comerciales para el terminal de cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Me pregunto qué principio se utiliza para poner los productos en esta pancarta
¿y los productos de los vendedores autorizados van allí? He hojeado 30 páginas y no he visto el mío...
Yo no me meto. Llevo 26 años programando sin parar.
Las advertencias son esencialmente errores si hablamos del sector financiero. Y todos los miles de informes de "pérdida de señal, pérdida de precisión, pérdida en los fantasmas, etc." son veredictos sobre la calidad del código. Por lo visto, no entiendes bien las implicaciones.
Por favor, facilite de forma suficientemente completa el trozo de código que el compilador ha señalado como error.
Sin ella toda esta discusión parece antiestética e injusta.
De acuerdo, Renat, estos argumentos sobre la "calidad del código" son irrelevantes para el tema de discusión, ya que aquí sólo se habla de la compilabilidad, es decir, de la viabilidad del código. Y la pérdida de precisión, etc. - esto es una cuestión personal del programador, es decir, su responsabilidad. La conversión implícita, por ejemplo, de int a short, no está prohibida por la norma del lenguaje, ¿verdad? Entonces, ¿por qué estamos predicando ahora?
Vale, he encontrado uno de estos fallos:
lo que me sale en el registro:
'CClass' - declaración sin tipo TestScript.mq5 16 9
'CClass' - coma esperada TestScript.mq5 16 9
En las versiones anteriores todo iba bien.
De acuerdo, Renat, estos argumentos sobre la "calidad del código" son irrelevantes para el tema de discusión, ya que aquí sólo hablamos de la compilabilidad, es decir, de la viabilidad del código. Y la pérdida de precisión, etc. - esto es una cuestión personal del programador, es decir, su responsabilidad. La conversión implícita, por ejemplo, de int a short, no está prohibida por la norma del lenguaje, ¿verdad? Entonces, ¿por qué estamos predicando ahora?
Vale, he encontrado uno de estos fallos:
lo que me sale en el registro:
En las versiones anteriores todo iba bien.
Sí, este fallo ya se discutió (probablemente, con A100) y se solucionó el 4 de mayo. Se excedió con el control de tipos, aparentemente.
Adjunto el último MetaEditor build 1329, que no tiene este error. Por favor, compruébelo allí.
El lanzamiento de MT5 será el 12 de mayo.
Estaba bien en las construcciones anteriores.
En tu código, no estás devolviendo un puntero const a un objeto privado. Resulta que las funciones de terceros (en términos de visibilidad de las variables) pueden cambiar aparentemente algo que no debería ser arquitectónicamente accesible para ellos, ya que el programador ha especificado privado.
Siempre que quiero devolver un puntero a un objeto privado, necesariamente especifico un modificador const. En tu caso yo le pondría un alabeo.
No soy de los que vuelan alto, por eso pregunto. ¿Hay que usar este código en algún sitio o es que da pereza poner la const?
Dos días desperdiciados prácticamente en su totalidad (a mi edad ya es mucho), y tenía previsto utilizarlos de una manera ligeramente diferente.
Así que, una vez más, me quito el sombrero ante A100 por su paciencia. Yo mismo estoy cansado de esto, me resulta más fácil sentarme en la vieja build, que funciona bien, que buscar las causas de los errores en la nueva build, trabajando en el servicio de atención al cliente. ¿O alguien me pagará por este trabajo?
Sí, servicedesk es una cosa genial para que los probadores de terceros lo hagan gratis. Obviamente no se hizo para eso, pero de hecho se ha convertido exactamente en el empleador de los probadores de terceros que trabajan gratis. Si no fuera por estos informes de errores, el compilador habría tardado mucho más en compilar.
Todo el mundo argumentará que debería haber una retribución por encontrar un error, como es la práctica en el mundo. A100 debería recibir el sueldo del examinador estatal. Y aparentemente el salario de un año de probador.
Sí, este error ya ha sido discutido (quizás con A100) y solucionado desde el 4 de mayo. Al parecer, se han excedido en el control del tipo.
Adjunto la última compilación 1329 de MetaEditor que no contiene este error. Por favor, compruébelo allí.
El lanzamiento de la MT5 será el 12 de mayo.
Comprobado. Ahora casi no hay errores de compilación, salvo algunas maravillas extrañas que no puedo reproducir por separado del programa, pero que consigo evitar por algún medio aleatorio.
A continuación se muestra un código de ejemplo del área problemática que voy a comentar. De nuevo, compila bien por separado pero genera un error en mi programa.
Si añade una línea en la función Main en cualquier lugar (por ejemplo, después de return):
work.Set(arr[0]);
se compila normalmente.
El programador parece haber ido demasiado lejos en la optimización.
Y también hay algunos fallos en el tiempo de ejecución. Por ejemplo, asigno un valor a algún miembro de una estructura, pero luego resulta que el valor que hay es antiguo, es decir, no se asignó nada. Si añado una línea con alguna operación arbitraria cerca, todo se vuelve normal. Estos bugs han empezado desde aquella build de otoño en la que se optimizó el compilador. En definitiva, todo sigue en bruto.
Además, la compilación en sí sigue tardando 20 segundos, mientras que la compilación 1159 sólo tardaba 1-2 segundos. Al mismo tiempo, no noto ningún aumento significativo de la velocidad de mis programas, la ganancia está dentro del 10-20%. Así que puedes olvidarte de esas historias sobre el aumento de velocidad de 2 a 10 veces. Puede que ocurra con muestras de prueba especialmente seleccionadas, pero tenemos aplicaciones reales, no falsas.
En total, la compilación es entre 10 y 20 veces más lenta para obtener un poco más de rendimiento. En mi opinión, no merece la pena. El tiempo que pierde el programador es mucho más valioso.
Todavía estoy obligado a permanecer en la construcción 1159.
En tu código, no estás devolviendo un puntero const a un objeto privado. Resulta que las funciones de terceros (en términos de visibilidad de las variables) pueden cambiar aparentemente algo que no debería ser arquitectónicamente accesible para ellos, ya que el programador ha especificado privado.
Siempre que quiero devolver un puntero a un objeto privado, necesariamente especifico un modificador const. En tu caso yo le pondría un alabeo.
No soy de los que vuelan alto, por eso pregunto. ¿Hay que usar este código en algún sitio o es que da pereza poner la const?
Sólo oculto un array en privado mientras los objetos CClass en sí están disponibles para un usuario para su acceso completo, ese es el propósito. Si lo necesitara sólo para leer, pondría const.
Todos apoyarán que haya una retribución por encontrar un error, como es la práctica en el mundo. A100 debería tener un sueldo de probador estatal. Y aparentemente el salario de un año de probador.
No sé si se trata de un error o simplemente de una descripción errónea de los métodos CDealInfoPositionId() yTicket(). He escrito el siguiente código
resultado
He añadido una solicitud para el historial de ofertas utilizando la funciónHistorySelect().
resultado
En private sólo oculto el array, y los objetos CClass en sí están a disposición del usuario para su acceso completo, ese es el propósito. Si necesitara que fuera sólo de lectura, pondría const.
Ya veo. ¿Puede decirme en qué construcciones puede ser útil? Entiendo que con este enfoque no se puede hacer nada con el propio array (redimensionar, intercambiar elementos, etc.). eliminar, sin embargo, puede aplicarse...
Supongo que lo haces en algún lugar con una plantilla, para que haya la misma sintaxis del operador [] para los diferentes tipos de objetos. En general, ¿podría mostrar el uso de esta construcción cuando sea conveniente?