¿Hay alguna investigación (o mejor uso) de RAII en los lenguajes de GC?

Question

Nota: Object Lifetime RAII no usa/con alcance de bloque RAII

Parece posible utilizar una categoría de gc adicional, objetos de vida corta (consulte la categoría de gc con cierta frecuencia), objetos de larga vida (revise la categoría de gc con menos frecuencia) y objetos de recursos (verifique la categoría de gc con mucha frecuencia). O posiblemente con una referencia adicional de recuento de gc para objetos de recursos.

Parece que usar/con estilo puede tener algunos beneficios al promover un estilo más funcional (perdóneme si estoy equivocado y este no es el estilo funcional) de E/S que desalenta la cantidad de E/S repartidas sobre el lugar frente a la flexibilidad de RAII basada en objetos (porque es más fácil). Pero algunos problemas probablemente requieran un seguimiento difícil de los recursos.

¿Hay razones además de evitar complejidad y velocidad de gc, que esto no se ha hecho en los lenguajes principales? (Entiendo que algunos idiomas usan el recuento de referencias como parte de gc en sus implementaciones principales y como RAII puede funcionar allí, pero como creo que su especificación no especifica el recuento de referencias para algún tipo de objetos/o todos los objetos y que otras implementaciones utilizadas por personas no cuentan con recuento de referencias, limitando el uso de la vida del objeto RAII en esos idiomas.

PS : ¿Tienen RAII tipo C++ en perl?

Answer 1

Muchos lenguajes hacen que sea mucho más fácil escribir un procesador de bloque interno personalizado ^† que tradicionalmente en C++ (esto puede haberse abordado en los borradores actuales del último estándar). Cuando los tiene, gran parte del requisito del uso de RAII para el manejo exacto de los recursos se vuelve mucho menos apremiante; usted puede hacer algo como esto:

using (Transaction t = makeTX()) { 
    // blah 
} 

en lugar de:

{ 
    Transaction t = makeTX(); 
    // blah 
} 

No hay una gran diferencia realmente, excepto que cuando se tienen varios anidados using constructos que es mucho más claro cuál es el orden de liberación de recursos es. (También es más fácil hacer un manejo especial en el caso de que se emita una excepción, lo que es útil para cosas como transacciones en las que desearía revertir el error, pero no espero que todos estén de acuerdo conmigo allí). que hay muchas maneras diferentes de escribir construcciones using, algunas mucho más pesadas que otras, pero en realidad no necesitamos explorar las diferencias aquí.

Dado que el manejo exacto de los recursos se maneja de esta manera diferente, hay mucha menos demanda del estilo C++ RAII y es viable usar Garbage Collection (GC), ya que maneja casos complejos (es decir, en cualquier lugar donde es difícil vincular la duración del objeto a un alcance específico) mucho más fácilmente. Para ser justos, hay casos en los que necesita una administración de recursos exacta con una vida no trivial, pero esos casos son desagradables para todos.

Perl usa Garbage Collection y tiene bloques de subrutinas baratos, al igual que la mayoría de los lenguajes de scripting en una forma u otra (porque la división entre código y datos es más flexible en lenguajes de scripts que las langs compiladas más tradicionales). El único lenguaje de scripting grande que conozco que no utiliza GC es Tcl, y eso se debe a que el sistema de valores no tiene garantizado bucle por razones semánticas técnicas, por lo que el conteo de referencias es suficiente. Los bloques de código todavía son muy baratos allí.

Si miramos los lenguajes compilados principales (es decir, no los lenguajes de scripting) entonces realmente vemos una división en alrededor de 1990.Los idiomas de antes (incluido C++) tienden a no asumir la recolección de basura (con algunas excepciones como Lisp, Smalltalk y los lenguajes de programación funcional) mientras que los lenguajes posteriores a ese punto (notablemente Java y C#) hacen. Supongo que hubo un cambio filosófico sustancial en ese punto, probablemente junto con algunas implementaciones inteligentes que abordaron los problemas más atroces en GC antes de ese punto. Cuando tienes GC, simplemente no piensas en RAII como una solución; está muy enraizado en el modelo del mundo de C++.

---

^{† acabo de hacer ese término para arriba.}