Errores, fallos, preguntas - página 493
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
Yo no discuto.
pero de esta manera
hay un redondeo de todos modos, ¿debería hacerlo?
Los promotores.
Accidentalmente hice un bucle en el procesamiento de los ticks en Expert Advisor, tras lo cual apareció un error crítico sobre el desbordamiento de pila.
El problema es que no hay información específica en el mensaje sobre qué y dónde ocurrió exactamente.
Sugiero que se aclare el texto de este mensaje, si es posible que se quieran detectar estos problemas (como llamar a un método de la clase desde un método llamado) en la fase de compilación.
La razón por la que iCustom() asigna valores arbitrarios a esas celdas de la memoria intermedia, que en realidad no estaban llenas de nada, no me queda clara, así como la razón por la que no se puede evitar de ninguna manera.
Supongo que tiene algo que ver con la asignación de memoria para la correspondiente matriz de datos del buffer del indicador.
Esta operación de iCustom(), cuando es imposible determinar el origen y la veracidad de los datos, me parece inadmisible y crea riesgos adicionales para el usuario.
Si iCustom() asigna valores arbitrarios e inconsistentes con los reales a las celdas del buffer de todos modos,
¿por qué no asigna valores iguales a Empty_Value a estas celdas como está implementado en MT4?
Así, al menos, su situación quedaría clara.
Los promotores.
..........., si es posible quiere detectar problemas como este (como llamar a un método de la clase desde un método llamado) en tiempo de compilación.
Estoy en contra. Haría que el compilador fuera excesivamente complicado y, por tanto, menos fiable.
Depende del programador el seguimiento de la recursión incorrecta.
Pero me gustaría que el mensaje de error contenga el nombre de la función que ha desbordado la pila.
Nadie más que el autor puede decidir con qué valores del búfer no utilizados debe rellenarse. Tú dices Valor_Vacío, pero yo, por ejemplo, quiero que sea 0, o algo más. Cualquiera que sea el valor que quieras, inicialízalo con él.
Esto es correcto y lógico. Pero el problema es que las celdas del buffer que el usuario no ha rellenado con nada (¡!), la función iCustom() las rellena periódicamente con basura arbitraria a su discreción ¿Se supone que es así?
Estoy en contra. Haría que el compilador fuera exorbitantemente complejo y, por tanto, menos fiable.
Depende del programador el seguimiento de la recursión incorrecta.
Pero me gustaría que el mensaje de error contenga el nombre de la función que desbordó la pila.
Sí, no complicamos a propósito el motor de trabajo (es nativo 32/64 después de todo) con meta-información.
La recursión suele ser fácil de atrapar: depende directamente del tamaño de las variables locales, y hay muy pocos lugares de este tipo en un programa.
Esto es correcto y lógico. Pero el problema es que las celdas del buffer, que el usuario no ha rellenado (¡!), la función iCustom() las rellena a su antojo con basura aleatoria ¿Se supone que debe ser así?
Si el indicador personalizado no llena su buffer correctamente, este indicador personalizado es culpable.
Y si este indicador personalizado envía sus resultados a través de iCustom, es doblemente culpable, ya que engaña a los usuarios.
Si un indicador personalizado no llena su buffer correctamente, significa que este indicador personalizado es culpable.
Y si este indicador personalizado da sus resultados a través de iCustom, es doblemente culpable, ya que engaña a los usuarios.
Si un indicador personalizado no llena su búfer correctamente, es este indicador personalizado el culpable.
Y si este indicador personalizado envía sus resultados a través de iCustom, es doblemente culpable, porque engaña a los usuarios.
Sigo sin entender, ¿qué le impide hacer el programa no sólo eficiente, sino también conveniente? Si no recuerdo mal, el razonamiento para la ausencia de inicialización incorporada de los búferes indicadores en el 5 es para optimizar la velocidad. En este caso el desarrollador de indicadores tiene que codificar por sí mismo las propias cadenas de inicialización ("ceros"), que antes en cuatros era realizado por el núcleo. Así, la eficiencia resultante no parece mejorar, y la usabilidad se resiente. Pero ya que se decidió hacerlo así por alguna razón, ¿por qué no hacerlo opcional? Es decir, podríamos introducir una #propiedad más, especificando si los búferes deben ser inicializados automáticamente o no.
Para resumir, repetiré la idea que ya expresé una vez: la tarea de la plataforma, que es MT, es proteger al usuario (el programador) de posibles "errores" en la medida de lo posible.
Esto es correcto y lógico. Pero el problema es que las celdas del buffer que el usuario no ha rellenado (¡!) con nada, iCustom() las rellena periódicamente con basura arbitraria a su discreción ¿Se supone que es así?
En realidad, es una regla común: la inicialización de arrays queda a discreción del usuario. Un array no inicializado contiene valores aleatorios de la memoria asignada. El usuario puede tener una buena razón para no inicializar la matriz innecesariamente (para ahorrar tiempo, por ejemplo). A veces ahorro tiempo de esta manera cuando estoy seguro de que no tendré que leer y "comer" esa basura antes de la información real.
No veo ninguna malicia por parte de MQ. Más bien me opondría a que "profilácticamente" empezaran a ralentizar mis programas.