Preguntas sobre POO en MQL5 - página 8
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 escriba borrar - todo funcionará correctamente, este pecado (me refiero a la superstición)) ) tomará el control del terminal y murmurará en su registro "48 bytes de memoria filtrada", luego "quedan 2 objetos de tipo CX" y "quedan objetos sin borrar"
HH: en la plantilla del indicador no hay Deinit() - esto es molesto
¿Por qué no crear un objeto y no un puntero? Entonces, tampoco se farfullará: el subsistema del terminal lo rastreará y lo clavará cuando sea necesario.
Funcionará sin borrar, pero no sirve de nada. Pero, ¿se ocupa el terminal de este problema? Sólo informa de las fugas de memoria, pero no dedica los mismos objetos.
El terminal se encargará de borrar los objetos creados por new en caso de que los punteros a los mismos se apilen en un objeto conocido por el terminal, por ejemplo, ArrayObj, List, etc.
¿Por qué no crear un objeto en lugar de un puntero? Entonces, tampoco se farfullará: el subsistema del terminal lo rastreará y lo clavará cuando sea necesario.
porquehttps://www.mql5.com/ru/forum/85652/page7#comment_12329866
Terminal se encargará de borrar los objetos creados por new en caso de que los punteros a los mismos se apilen en un objeto conocido por terminal, por ejemplo, ArrayObj, List, etc.
no siempre es conveniente la destrucción no supervisada, pero tendré que comprobarlo, tal vez me equivoque - rara vez uso CObject
porquehttps://www.mql5.com/ru/forum/85652/page7#comment_12329866
Bueno, este es un caso muy especial y grotescamente simplista, en mi opinión. Crear un objeto que no se pueda modificar, de modo que para cambiar sus campos haya que clavarlo y crear uno nuevo...
¿Y si tenemos que cambiar un par de campos del objeto y dejar otros campos con la información necesaria? IMHO - mejor cuidar la interactividad y la manejabilidad de cada objeto (gracias a la herencia), que sentarse con una pistola y disparar a los conejos a cada estornudo.
Aunque, para ser justos, a veces es más rápido matar y crear uno nuevo, que buscar uno entre un gran número y cambiarlo. A menos que, por supuesto, haya un enlace directo con él...
Bueno, este es un caso muy especial y grotescamente simplificado, en mi opinión. Crear un objeto que no se pueda modificar, de modo que para cambiar los valores de sus campos haya que clavarlos y crear uno nuevo...
¿Y si tenemos que cambiar un par de campos del objeto y dejar otros campos con la información necesaria? IMHO - mejor cuidar la interactividad y la manejabilidad de cada objeto (gracias a la herencia), que sentarse con una pistola y disparar a los conejos a cada estornudo.
Aunque, para ser justos, a veces es más rápido matar y crear uno nuevo, que buscar el necesario entre un gran número y cambiarlo. A menos que, por supuesto, tengas un enlace directo a él...
hmmm, estás muy lejos de la base.... sí, pero no así ))))
lo que sea cómodo, ¡esa es la forma de usarlo! - y estos ejemplos del "primer libro de texto de c++" se pueden tirar en su experiencia toda la vida.... Como ejemplo, he desmontado una parte decente del código de @fxsaber y me he obligado a usar #define tanto como sea posible - los códigos se volvieron no sólo más cortos, sino realmente más legibles y eliminaron los errores tipográficos - ¿enseñan tanto en los libros de C++? ;)
Aunque, para ser justos, a veces es más rápido matar y crear uno nuevo, que buscar uno necesario entre un gran número y cambiarlo. Por supuesto, si no hay una dirección directa hacia ella...
y sobre los fundamentos del libro... Según las "reglas de buena crianza" en programación, se espera lo siguiente: debes declarar una variable e inicializarla inmediatamente (esto permite evitar errores al depurar), en POO el constructor sirve para estos fines - creaste un objeto y lo inicializaste todo
si necesitas "sacar todo el código después de un simple objeto", necesitarás un método para reinicializar todos los campos de la clase - ¿por qué duplicar esto? - matar/crear = resultado.... pero, de nuevo, es una cuestión de gustos y de religión.
porquehttps://www.mql5.com/ru/forum/85652/page7#comment_12329866
no siempre se siente cómodo con la destrucción no supervisada, pero tendrá que comprobar, tal vez me equivoque - rara vez uso CObject
Pero sí que usas listas. Y allí es lo mismo. Bueno, a menos que la bandera de la gestión de la memoria FreeMode() no se restablece para la lista - en este caso el terminal no rastrear - todo se lleva a cabo por el usuario. Pero esta situación es necesaria para poder cambiar, borrar, ordenar y hacer algo más con una copia de la lista - de hecho la lista se crea con punteros a objetos, y si creas una nueva lista una copia de una de las listas, y empiezas a cambiar objetos en la nueva lista (hay punteros a objetos), entonces en la lista original se cambiarán los objetos (porque trabajamos con punteros). Eso es para mantener el original y juguetear con su copia, entonces usted necesita soltar la bandera de la gestión de la memoria para una copia: FreeMode(false) - entonces la copia se convierte en una copia independiente, y usted puede trabajar con seguridad con los objetos en ella, sin afectar al original. Y recuerde, que cuando se desvincula la copia de la lista del subsistema de la terminal, a continuación, para la eliminación de los objetos de la lista ahora responsable de nosotros mismos. Se puede rastrear y eliminar en OnDeinit(), eso en el caso más sencillo y si la lista de copias la conocemos de antemano, o crear una lista de objetos, que siempre coloca las listas recién creadas, no conocidas de antemano con la bandera de gestión manual de la memoria. Entonces el terminal rastreará este objeto de lista y eliminará correctamente las listas apiladas en él.
El terminal se encargará de borrar los objetos creados por new en caso de que los punteros a los mismos estén apilados en un objeto conocido por el terminal, por ejemplo, ArrayObj, List, etc...
Entonces tampoco habrá mensaje de fuga.
Entonces tampoco habrá un informe de una fuga.
Sí, no lo hará. Porque no habrá una fuga.
Si hemos creado un nuevo objeto en algún lugar y hemos recibido un puntero a él, debemos eliminar este objeto por el puntero dado. Esto significa que tenemos que seguir el puntero. Para este propósito, las listas o matrices de punteros a objetos, ofrecidas en SB, son muy buenas. Pero también puede ocuparse del seguimiento y control de los objetos recién creados. Pero, por mi parte, ¿para qué escribir toneladas de código si ya está previsto?
entonces deben eliminar este objeto por este puntero.
Pero, por mi parte, ¿para qué escribir toneladas de código si ya está previsto?
¿De qué toneladas estamos hablando? Todo lo que te has perdido lo informa el terminal y el lugar para borrarlo también es conocido - OnDeint() .... ¿Esta discusión se ha reducido a una discusión sobre un caballo esférico en el vacío? )))
hmm, tienes que estar bromeando ..... así, pero no así ))))
como es conveniente, ¡así es como debes usarlo! - y estos ejemplos del "primer libro de texto de s++" se pueden tirar en su experiencia toda la vida.... Como ejemplo, desmonté una buena parte del código de @fxsaber y me obligué a usar #define tanto como fuera posible - los códigos se volvieron no sólo más cortos, sino realmente más legibles y libres de errores - ¿enseñan eso en los libros de C++? ;)
Y sobre los fundamentos del libro... Las buenas reglas de crianza dicen: proclamar una variable e inicializarla inmediatamente (esto permite evitar errores al depurar), en POO el constructor sirve para este propósito - creas un objeto e inicializas todo
si necesitas "sacar todo el código después de un simple objeto", necesitarás un método para reinicializar todos los campos de la clase - ¿por qué duplicar esto? - matar/crear = resultado.... pero, de nuevo, es una cuestión de gustos y de religión.
No me refiero a la reinicialización completa de un objeto, sino a la parcial: cuando hay que cambiar un par de campos y un par de docenas de otros siguen manteniendo la información que se necesita... Podemos querer o no cambiar los campos, pero necesitamos métodos para cambiarlos. A menos que -de nuevo- estemos hablando de un simple objeto con un solo campo. Si hay dos o más, es posible que ya tenga que cambiar uno, dejando los otros sin modificar.
¿Pero quizás estamos hablando de cosas diferentes?