Preguntas sobre POO en MQL5 - página 9
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
¿de qué toneladas estamos hablando? todo lo que se pasó por alto será reportado por el terminal, el lugar donde se elimina también se conoce - OnDeint() .... ¿Se ha convertido esta discusión en un debate sobre un caballo esférico en el vacío? )))
No. Deja que el caballo cabalgue por donde debe.
Pero estamos hablando de la creación de objetos previamente desconocidos. Y no sólo conocemos sus propiedades, sino también el número de objetos creados.
Por supuesto, para un objeto podemos crear un puntero y trabajar con ese objeto mediante este puntero. Pero si no sabemos de antemano cuántos punteros vamos a necesitar, ¿qué clase de vacío es éste? Es sólo uno de los más simples e inmediatamente disponibles - para almacenar punteros en las listas. Se pueden tomar de la lista. Pues bien, cada objeto puede tener su propio identificador (el método Type()), mediante el cual se puede identificar el objeto puntero. Es posible identificar con precisión un objeto (además de su tipo el objeto puede estar dotado de otras propiedades, que lo distinguen de los objetos del mismo tipo).
En general - parece que estoy hablando de estructuras más complejas, que requieren la clasificación de los objetos, las listas para su almacenamiento y los métodos de trabajo con los objetos que no sólo pueden almacenar y dar información a petición, sino también "vivir y crecer" interactuando con el programa, de vez en cuando ellos mismos cambiar e informar sobre sus acciones.
Tal vez me he pasado de la raya y sólo he hablado de un objeto en el que dos campos deben cambiarse durante la inicialización y no deben cambiar de ninguna manera durante la vida del objeto. ¿De qué sirve tener un objeto si hay variables de entrada?
Nadie está obligado a borrar un objeto, excepto el que lo creó. Aunque esto ocurra en algunos casos, no es de fiar. Si lo has creado tú, lo borras.
Es cierto. Pero no estamos hablando de eso. ¿No es así?
Hablamos de métodos por los que los objetos no se pierden definitivamente, y se pueden encontrar de forma inequívoca.
Cuando crees un objeto, tenlo en cuenta y no lo pierdas, para que luego se elimine correctamente y no haya una fuga de memoria por pérdida del puntero del objeto (empezamos con la fuga de memoria en el ejemplo donde el puntero al objeto pasado a la función se reasignó al objeto recién creado en el cuerpo de la función).
Y cada uno tiene sus propias preferencias: a algunos les gusta una cosa, a otros otra. Pero tenemos que conocer cada uno de nuestros objetos -aunque sean dos o dos mil y pico- para poder borrarlos después. Y si los borraremos nosotros mismos por medio de delete o dejaremos que list los borre por medio de Clear() o en bucle por medio de list y delete o de alguna otra manera - no se trata de eso.
En general, me parece que estoy hablando de estructuras más complejas, que requieren la clasificación de objetos, listas para su almacenamiento y métodos de trabajo con objetos, que no sólo pueden almacenar y dar información a petición, sino también "vivir y evolucionar" interactuando con el programa, de vez en cuando cambiando ellos mismos e informando sobre sus acciones.
¿Quizás me he pasado de la raya y sólo tenemos que hablar de un objeto en el que dos campos deben ser cambiados en la inicialización y no deben cambiar de ninguna manera durante el tiempo de vida? ¿De qué sirve tener un objeto si hay variables de entrada?
Este es un concepto extraño de la POO. En primer lugar, la POO es conveniente: se escribe una vez y luego se crean nuevas instancias del objeto.
Volviendo al principio de la discusión, este es mi ejemplo, lo uso a menudohttps://www.mql5.com/ru/forum/160683/page861#comment_11840254
Tengo que limitar mi comercio a un intervalo de tiempo ahora y 2 la próxima vez... 4...
mi ejemplo de 2 clics está modificado para esta tarea:
No sé, pero pensando en categorías que la POO es sólo para envolver todo en una clase y ahí es un milagro - mi superclase y puede hacer ambas cosas... Y si la clase es de 10 cadenas, no necesitas OOP - ¿por qué limitarte y engañar a todos?
Yo uso la POO donde me conviene, la discusión se ha ido claramente a la religión - prohibir o usar la POO ))))
Esta es una idea extraña de la POO, la POO es en primer lugar conveniente - escribir una vez, luego crear nuevas instancias del objeto
Volviendo al principio de la discusión, este es mi ejemplo, lo uso a menudohttps://www.mql5.com/ru/forum/160683/page861#comment_11840254
Tengo que limitar mi comercio a un intervalo de tiempo ahora y 2 la próxima vez... 4...
mi ejemplo de 2 clics está modificado para esta tarea:
No sé, pero pensando en categorías que la POO es sólo para envolver todo en una clase y ahí es un milagro - mi superclase y puede hacer ambas cosas... Y si la clase es de 10 cadenas, no necesitas OOP - ¿por qué limitarte y engañar a todos?
donde me conviene, ahí es donde uso la POO, claramente la discusión se ha ido a la religión - prohibir o usar la POO ))))
Definitivamente, no soy yo quien se adentra en esta religión, ya que yo mismo utilizo activamente la OOP.
Por ejemplo: ¿y si necesitamos más intervalos? ¿Debemos crear otras nuevas? ¿Para qué? Si puede arreglárselas con una lista sin interferir con el código del programa.
Parece que estamos hablando de cosas diferentes. Estoy hablando de usabilidad, y tú estás... Yo también hablo de usabilidad, pero estás mostrando un código que no es usable. Tal vez sólo exagerado, por supuesto, y no lo entendí...
Por ejemplo: ¿qué pasa si se necesitan más intervalos? ¿Deben crearse nuevas redes de trabajo? ¿Qué sentido tiene? Si puedes arreglártelas con una lista sin interferir con el código del programa...
Si necesitamos usar listas o arrays de instancias de clases, no es un gran problema, pero es más fácil usar un array para este ejemplo y hacer un solo bucle:
Parece que estamos hablando de cosas diferentes. Estoy hablando de usabilidad, y tú... Yo también hablo de usabilidad, pero el código que muestras no es conveniente. Tal vez sea exagerado, por supuesto, y no lo entendí...
Desgraciadamente, es imposible escribir un código universal. Incluso si se escribe un código universal, su modificación posterior será un proceso tedioso y, como consecuencia, el código universal consumirá más recursos - en general, se puede hablar de esto siempre, una vez escribí que uno de los programadores famosos dijo -"¡el código debe realizar su tarea! - es suficiente". Todo lo demás es... bueno, es un deseo de liarla o... ¡digamos que para crear! )))
///
Por ejemplo: ¿qué pasa si se necesitan más intervalos? ¿Deben crearse nuevas redes de trabajo? ¿Qué sentido tiene? Si puede arreglárselas con una lista sin interferir con el código del programa.
///
Entonces no habrá parámetros de intervalo numérico en la ventana de propiedades. No podrá optimizarlos. No es una opción.
Crear un nuevo objeto para cada intervalo tampoco es la mejor opción. Aun así, el rendimiento será más lento. Si tuviéramos que crear una clase, deberíamos crear una que añadiera los parámetros de los intervalos en un array. Será más rápido.
no hay ninguna diferencia entre crear una clase o una función en la que se añaden() varios parámetros, o crear varias clases con parámetros individuales
SZZ: no olvides que si escribes una gran función en forma de una larga "cinta de caballo" - la caché de la CPU no siempre se utilizará de forma efectiva, aunque puede haber una ganancia en dicha "cinta de caballo" cuando se predice transiciones.... Sólo las pruebas pueden demostrarlo, pero en un PC específico y en un compilador específico...
Entonces no habrá parámetros de intervalo numérico en la ventana de propiedades. No podrás optimizarlo. No es una opción.
Crear un nuevo objeto para cada intervalo tampoco es la mejor opción. Al fin y al cabo, esto hará que el rendimiento sea más lento. Si tuviéramos que crear una clase, deberíamos crear una que añadiera los parámetros de los intervalos en un array. Sería más rápido.
De acuerdo. De nuevo, todo se reduce a los métodos para establecer los campos de pago. Y cómo transferirlos de los parámetros de entrada al objeto que almacena todos los intervalos es una cuestión de técnica. Aunque es posible volver a crear todos los objetos de la lista de intervalos y cuando se cambia sólo uno de ellos - es una cuestión de practicidad y de "molestarse/no molestarse" en cambiar los datos al escribir el código.
¿Puedes explicar el sentido de crear un objeto dinámico utilizando el operador new?
Cuando un objeto se crea automáticamente, el objeto de clase se crea en la pila y es más rápido que un objeto dinámico en términos de tiempo de ejecución.
Cuando se crea un objeto dinámicamente, un objeto de clase se crea en la memoria (en el montón) involucrando al administrador de memoria del SO, el proceso es más lento.
Estas son las preguntas:
Si la creación automática es más rápida, ¿por qué es mejor utilizar objetos dinámicos?
¿Controlar explícitamente la asignación de memoria?
¿Eliminar un posible desbordamiento de pila?
¿Y no perder un objeto inesperadamente?
¿Porque si la pila se desborda, el objeto se borrará automáticamente?
Buenas tardes. La memoria del ordenador tiene el mismo rendimiento independientemente de si se utiliza en un contexto de pila o de montón. La gestión de la memoria dinámica en sí misma depende de la implementación del recolector de basura: por ejemplo, puede ser el recuento de referencias como en Python (variante más lenta) o el análisis de las épocas de generación de objetos con el recorrido del gráfico de ejecución en el proceso de fondo (Net CLR). Se desconoce qué variante se utiliza en MQL, pero podemos suponer que es extremadamente eficiente, porque el usuario de MQL5 tiene acceso al operador de borrado directamente, lo que simplifica enormemente el trabajo de la propia GC. Por lo tanto, su preocupación por la sobrecarga al utilizar new es infundada - siéntase libre de utilizar la memoria dinámica.
En cuanto al "desbordamiento de la pila", la única forma de encontrar este caso en los sistemas modernos es cuando se utiliza una recursión compleja o se comete un error en el algoritmo recursivo. Un programa moderno siempre trabaja en modo protegido por OC en el espacio de direcciones virtual, con carga dinámica de páginas de memoria, así que no te preocupes: la pila no se desbordará:)