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

 
borilunad:

Sr. ¡Pansa! ¿Por qué no usa el botón SRC para poner su código? ¿Así mejor o Ud. tiene alguna duda?

¡Buena suerte!

¡Hola, borilunad!
quiero preguntar dónde se consigue el SRC?
panza
 
 
pansa:
Hola borilunad!
quiero preguntar donde consigues el SRC?
pansa

Cuando respondas, mira un poco hacia arriba y a la izquierda del vídeo verás un botón SRC. Haz clic en él y se abrirá un perímetro para pegar el código. Buena suerte.

Por cierto, ¡muy acertada y "elocuentemente" señalada la ubicación del CRS por Constantino!

 
7Konstantin7:

Hola Konstantin, ¿cómo te va en el trading manual? Supongo que ya te has convertido en un asesino, ¿no?
 
Renat:

Entiendo que algunas personas se pongan histéricas después de familiarizarse con los analizadores estáticos.

Pero sólo después de que algunos entiendan lo que un compilador debe (exactamente debe) hacer. Estamos en 2014 y los compiladores ordinarios llevan al menos 10 años de retraso en el control de calidad y se concentran solo en las optimizaciones.

Para información: el compilador Intel C++ todavía no se ha recuperado de sus defectos - genera constantemente errores internos de compilación en nuestros proyectos. Es decir, no mastica grandes proyectos y produce sus propios errores. Y los mitos sobre sus extraordinarias propiedades de optimización también han quedado obsoletos: todos los demás han ajustado mucho sus niveles de optimización.

En un lenguaje tan peligroso y suicida como el C++ hay tantas llaves e interruptores de compilación para que los programadores confiados puedan compilar toneladas de código antiguo y copiado de la nada sin calambres nerviosos :)

Un compilador, en primer lugar, debe compilar más que analizar y debe compilar preferentemente con buena calidad, lo que suele requerir flexibilidad y personalización.

Es razonable crear analizadores de código estático y otras herramientas similares como utilidades separadas cuyas funciones pueden realizarse con mayor calidad de esta manera que con el compilador.

Es razonable entender que el análisis estático de código y otras cosas útiles similares ayudan a detectar sólo algunos errores, es decir, los relacionados tanto con la falta de atención como con la baja habilidad de un programador. Los errores de diseño, los errores lógicos, los errores del tipo "se olvidó de implementar" y otros errores similares no son detectados por los analizadores estáticos o herramientas similares. Que es exactamente lo que podemos ver en MT4.

En su momento, el compilador de Microsoft también era fácil de "romper" por errores internos. Las versiones más recientes también son más estables, incluidas las de Intel. En cuanto a la optimización, normalmente no se necesita nada extraordinario, sólo una buena y sólida optimización, y la de Intel se basa en un profundo conocimiento de la arquitectura y los mecanismos de sus propios procesadores. Sería extraño pensar que fuera peor para Intel que para otros.

Los conmutadores de compilación están pensados principalmente para ajustar el compilador de forma flexible a los requisitos (parciales) de un proyecto, y las opciones para facilitar la compilación de código antiguo son sólo un extra.

Si el lenguaje C++ es tan peligroso y suicida, entonces ¿por qué el primer MQL4 basado en C fue "mejorado" a MQL4++ y MQL5 basado exactamente en C++?

 

simpleton:

Es razonable entender que el análisis estático de código y otras herramientas útiles similares ayudan a detectar sólo unos pocos errores, es decir, los relacionados tanto con la falta de atención como con la baja habilidad de los programadores. Los errores de diseño, los errores lógicos, los errores del tipo "se olvidó de implementar" y otros errores similares no son detectados por los analizadores estáticos o herramientas similares. Que es exactamente lo que se puede ver en MT4.

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, la cáscara funcional es una parte integral del desarrollo de cualquier código para el diseño de chips. Por otro lado, muchos programadores ni siquiera tienen idea de estas pruebas funcionales cuando escriben proyectos de software habituales, es porque escribir estas pruebas desde cero puede llevar más tiempo que cuando se escribe el proyecto en sí y se justifica sólo cuando hay un requisito de escribir código de alta calidad o hay muchas versiones del mismo proyecto. Por otro lado, un entorno de pruebas bien escrito reduce considerablemente el 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 y primaria.

 

Simplón, qué tontería.

Sólo cuando se llegue al nivel de control de calidad total, se entenderá. Mientras tanto, sigues en el nivel de percepción de un programador narcisista individual, y seguirás pensando "es razonable no controlarme, que el control sea por utilidades separadas nunca ejecutadas".

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

 
Renat:

A diferencia de C++, MQL no es peligroso en absoluto

Los fallos en el propio compilador de C++ son bastante raros.

Los fallos del compilador de MQL son habituales ahora (he visto errores internos del compilador para MQL mucho más a menudo que para VS).

Los fallos en la ejecución del código MQL también son un fenómeno recurrente hoy en día.

 

Los fallos se están solucionando, pero estamos añadiendo y mejorando mucho en paralelo.

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

 
Renat, quiero: namespace, pegar en macros, inclusión múltiple de archivos de cabecera, undef, unión. Todo como en C++.