Ayuda con la POO - página 4
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
Oficialmente, sí. Extraoficialmente, muchas cosas indican que existe:
Hay una indicación suficiente y completa de que no hay un recolector de basura en emcool - la eliminación es obligatoria después de nuevo.
Hay un indicio suficiente y suficiente de que no hay un recolector de basura en emcool - borrar es obligatorio después de nuevo.
Por lo que recuerdo, uno de los promotores reconoció que hay un recolector de basura. Pero para el usuario "como que no existe".
En cuanto a la pareja nueva-borrada, estoy a favor. En general, los objetos que solicitan recursos deben ser responsables de ellos. Hay excepciones, como la "fábrica de objetos" - pero allí se asume específicamente que la responsabilidad de los objetos creados recae en quien solicitó estos objetos a la fábrica.
No me gusta la situación de los idiomas en los que está presente lo nuevo, pero no es necesario borrarlo, ya que "el sistema eliminará las cosas innecesarias". Esto no sólo reduce potencialmente el rendimiento (cuando no se eliminan los objetos innecesarios), sino que también relaja al codificador, permitiéndole no preocuparse por las consecuencias de sus acciones.
Realmente no me gusta la situación de los idiomas en los que lo nuevo está ahí, pero la eliminación no es necesaria, diciendo que "el sistema eliminará lo innecesario". Esto no sólo reduce potencialmente el rendimiento (cuando no se eliminan los objetos innecesarios), sino que también relaja al codificador, permitiéndole no preocuparse por las consecuencias de sus acciones.
Por otro lado, la productividad suele mejorar. La eliminación manual lleva mucho tiempo en el hilo principal. + la eliminación se hace elemento por elemento. Compara las dos versiones del guión en este hilo, por ejemplo. La diferencia de velocidad es de varias veces. La eficiencia de la memoria también aumenta. Porque el recolector de basura mueve objetos compactados entre sí. Si lo gestionas manualmente, se crean agujeros de memoria libres que no son tan fáciles de reutilizar. Además, el recolector de basura trabaja en un hilo diferente. El tiempo básico no se pierde. En definitiva, un plus.
Por el contrario, la productividad suele aumentar. La eliminación manual lleva una cantidad de tiempo considerable en la corriente principal. + la eliminación se hace elemento por elemento. Compara dos versiones del guión en este hilo, por ejemplo. La diferencia de velocidad es de varias veces. La eficiencia de la memoria también aumenta. Porque el recolector de basura mueve objetos compactados entre sí. Si lo gestionas manualmente, se crean agujeros de memoria libres que no son tan fáciles de reutilizar. Además, el recolector de basura trabaja en un hilo diferente. El tiempo básico no se pierde. En definitiva, es una ventaja.
Vasily, lo siento, pero no entiendes en absoluto de lo que intentas hablar. En absoluto y de ninguna manera.
Al menos lee en Wikipedia lo que es un recolector de basura. Su principal peculiaridad es que elimina los objetos con los que se ha perdido la comunicación.
Sólo que en este caso se llamaría recolector de basura. Esos dos guiones son de una historia diferente. No hay que confundir el regalo de Dios con un huevo.
¿Y por qué un recolector de basura aumentaría de repente la productividad? Es un acolchado más entre el código útil y el hardware, y no uno débil.
Por lo que recuerdo, uno de los promotores admitió que hay un recolector de basura. Pero para el usuario es "como si se hubiera ido".
///
Este debe ser el "recolector de basura" que da un mensaje sobre la pérdida de memoria al final del trabajo.
Tal vez incluso borre los objetos abandonados. Pero aunque los elimine, hay una gran
diferencia: sólo los borra al final del trabajo. ¿Y si en un ciclo de varios miles se crean nuevos objetos?
¿nuevos objetos? El programa será inoperable, no hay suficiente memoria.
Un verdadero ensamblador borra los objetos perdidos durante la operación del programa, no
sólo al final del programa. Por eso se permite un estilo de programación especial.
podemos multiplicar los objetos en cualquier condición y en cualquier cantidad.
Por el contrario, la productividad suele aumentar. La eliminación manual lleva una cantidad de tiempo considerable en la corriente principal. + la eliminación se hace elemento por elemento. Compara dos versiones del guión en este hilo, por ejemplo. La diferencia de velocidad es de varias veces. La eficiencia de la memoria también aumenta. Porque el recolector de basura mueve objetos compactados entre sí. Si lo gestionas manualmente, se crean agujeros de memoria libres que no son tan fáciles de reutilizar. Además, el recolector de basura trabaja en un hilo diferente. El tiempo básico no se pierde. En definitiva, un plus.
Hmm... ¿Y en un recolector de basura, el borrado no es elemental? Por no hablar de que otro hilo, cuando no hay núcleos libres, es realizado por el mismo núcleo, y ralentiza el hilo principal.
En mi opinión, en general, con una cuidadosa consideración, la eliminación de la basura por parte del usuario es siempre más eficiente que la eliminación por parte del recolector de basura. Sin embargo, si no te importa, el recolector de basura ciertamente gana.
Por eso no me gusta el recolector de basura, porque fomenta este tratamiento tan indiferente de los recursos.
Este debe ser el "ensamblador" que da el mensaje sobre las fugas de memoria cuando el trabajo está terminado.
Probablemente incluso borre los objetos sobrantes. Pero aunque los borre, hay un gran
diferencia: sólo los borra al final del trabajo. ¿Y si en un ciclo de varios miles se crean nuevos objetos?
¿nuevos objetos? El programa será inoperable, no hay suficiente memoria.
Un verdadero ensamblador borra los objetos perdidos durante la operación del programa, no
sólo al final del programa. Por eso se permite un estilo de programación especial.
podemos multiplicar los objetos en cualquier condición y en cualquier cantidad.
Así es. Por eso no me gusta trabajar con ensamblador - el usuario no presta atención, cuántos objetos ha creado y dónde.
Básicamente, incluso simplifica el desarrollo de alguna manera: no tienes que recordar borrar el ocupado. El constructor encuentra el momento en que el objeto ya no es referenciado, y lo elimina. Pero esta posición me disgusta. Es por esta posición que tenemos programas que se ejecutan cada vez más lentamente, que necesitan recursos de hardware cada vez más potentes para tareas de similar complejidad.
Vasily, lo siento, pero no entiendes nada de lo que intentas argumentar. Nada en absoluto y de ninguna manera.
Hmmm... ¿Y en el recolector de basura el borrado no es elemental? Por no hablar de que otro hilo, cuando no hay núcleos libres - se hace por el mismo núcleo, y ralentiza el hilo principal.
En mi opinión, en general, con una cuidadosa consideración, la eliminación de la basura por parte del usuario es siempre más eficiente que la eliminación por parte del recolector de basura. Sin embargo, si no te importa, el recolector de basura ciertamente gana.
Por eso no me gusta el recolector de basura, fomenta este mismo tratamiento indiferente de los recursos.
En lugar de hacer suposiciones sobre el funcionamiento de un recolector de basura, basta con comparar la velocidad de eliminación automática de objetos con la eliminación manual. Todas las fantasías se desvanecerán de inmediato.
comparar la velocidad de la eliminación automática de objetos y la eliminación manual de objetos.
La respuesta es preferiblemente inmediata. No siempre hay tiempo para hacer experimentos.