¿Cuándo tiene RAII una ventaja sobre GC?

Question

considerar esta clase simple que demuestra RAII en C++ (Desde la parte superior de la cabeza):

class X { 
public: 
    X() { 
     fp = fopen("whatever", "r"); 
     if (fp == NULL) 
     throw some_exception(); 
    } 

    ~X() { 
     if (fclose(fp) != 0){ 
      // An error. Now what? 
     } 
    } 
private: 
    FILE *fp; 
    X(X const&) = delete; 
    X(X&&) = delete; 
    X& operator=(X const&) = delete; 
    X& operator=(X&&) = delete; 
} 

No puedo lanzar una excepción en el destructor. Estoy teniendo un error, pero no hay manera de informarlo. Y este ejemplo es bastante genérico: puedo hacerlo no solo con archivos, sino también con, por ejemplo, subprocesos, recursos gráficos, ... Observo cómo, p. la página wikipedia RAII barre todo el tema debajo de la alfombra: http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

Me parece que RAII solo es útil si se garantiza que la destrucción ocurrirá sin error. Los únicos recursos que conozco con esta propiedad es la memoria. Ahora me parece que, por ejemplo, Boehm descarta de manera convincente la idea de que la gestión manual de la memoria es una buena idea en cualquier situación común, entonces, ¿dónde está la ventaja en la forma C++ de usar RAII?

Sí, lo sé GC es un hereje poco en el mundo de C++ ;-)

Answer 1

RAII, a diferencia de GC, es determinista. Sabrá exactamente cuándo se lanzará un recurso, en lugar de "en algún momento en el futuro se lanzará", dependiendo de cuándo el GC decide que necesita volver a ejecutarse.

Ahora, veamos el problema real que parece tener. Esta discusión surgió en la sala de chat < C++ > hace un momento acerca de lo que debe hacer si el destructor de un objeto RAII puede fallar.

La conclusión fue que la mejor forma sería la de proporcionar una close(), destroy() o función miembro similares específica que es llamada por el destructor pero también puede ser llamado antes de eso, si quiere eludir la "excepción durante la pila relajarse" problema. Luego establecería un indicador que evitaría que se llamara en el destructor. std::(i|o)fstream, por ejemplo, hace exactamente eso: cierra el archivo en su destructor, pero también proporciona un método close().

Answer 2

Este es un argumento del hombre de paja, porque no estamos hablando de recolección de basura (cancelación de asignación de memoria), que está hablando gestión de recursos generales.

Si hizo un mal uso de un recolector de basura para cerrar archivos de esta manera, entonces tendría la misma situación: tampoco podría lanzar una excepción. Las mismas opciones estarían abiertas para usted: ignorar el error o, mucho mejor, iniciar sesión.

Answer 3

El mismo problema ocurre en la recolección de basura.

Sin embargo, vale la pena señalar que si no hay ningún error en su código ni en el código de la biblioteca que alimenta su código, la eliminación de un recurso será nunca. delete nunca falla a menos que haya dañado su pila. Esta es la misma historia para cada recurso. La falla en la destrucción de un recurso es una falla que termina la aplicación, no una agradable excepción de "manejame".

Answer 4

P. ¿Cuándo tiene RAII una ventaja sobre GC?

A. En todos los casos donde los errores de destrucción no son interesantes (es decir, no tiene una forma efectiva de manejarlos de todos modos).

Tenga en cuenta que incluso con la recolección de basura, que tendría que ejecutar el 'dispuestos' (cierre, la liberación de lo que sea) la acción de forma manual, por lo que sólo puede mejorar el patrón RIIA de la misma manera:

class X{ 
    FILE *fp; 
    X(){ 
     fp=fopen("whatever","r"); 
     if(fp==NULL) throw some_exception(); 
    } 

    void close() 
    { 
     if (!fp) 
      return; 
     if(fclose(fp)!=0){ 
      throw some_exception(); 
     } 
     fp = 0; 
    } 

    ~X(){ 
     if (fp) 
     { 
      if(fclose(fp)!=0){ 
       //An error. You're screwed, just throw or std::terminate 
      } 
     } 
    } 
} 

Answer 5

Primero: no se puede hacer nada realmente útil con el error si el objeto de archivo está GCed y no cierra el ARCHIVO *. Entonces los dos son equivalentes en la medida de lo posible.

En segundo lugar, el patrón de "correcta" es la siguiente:

class X{ 
    FILE *fp; 
    public: 
    X(){ 
     fp=fopen("whatever","r"); 
     if(fp==NULL) throw some_exception(); 
    } 
    ~X(){ 
     try { 
      close(); 
     } catch (const FileError &) { 
      // perhaps log, or do nothing 
     } 
    } 
    void close() { 
     if (fp != 0) { 
      if(fclose(fp)!=0){ 
       // may need to handle EAGAIN and EINTR, otherwise 
       throw FileError(); 
      } 
      fp = 0; 
     } 
    } 
}; 

Uso:

X x; 
// do stuff involving x that might throw 
x.close(); // also might throw, but if not then the file is successfully closed 

Si "hacer cosas" tiros, entonces es más o menos no importa si el identificador de archivo está cerrado con éxito o no. La operación ha fallado, por lo que el archivo es normalmente inútil de todos modos. Alguien más arriba en la cadena de llamadas puede saber qué hacer al respecto, dependiendo de cómo se use el archivo, quizás debería eliminarse, quizás dejarse solo en su estado parcialmente escrito. Independientemente de lo que hagan, deben ser conscientes de que, además del error descrito por la excepción que ven, es posible que el búfer de archivo no se haya descargado.

RAII se utiliza aquí para recursos de gestión. El archivo se cierra sin importar nada. Pero RAII no se usa para detectando si una operación ha tenido éxito - si desea hacerlo, llame al x.close(). El GC tampoco se usa para detectar si una operación ha tenido éxito, por lo que las dos son iguales en ese conteo.

Se produce una situación similar cada vez que usa RAII en un contexto donde está definiendo algún tipo de transacción: RAII puede retrotraer una transacción abierta en una excepción, pero suponiendo que todo va bien, el programador debe transacción.

La respuesta a su pregunta: la ventaja de RAII, y la razón por la que termina descargando o cerrando objetos de archivo en finally cláusulas en Java, es que a veces desea que se limpie el recurso (en la medida de lo posible) ser) inmediatamente al salir del alcance, para que el próximo bit de código sepa que ya ha sucedido. Mark-sweep GC no garantiza eso.

Answer 6

Las excepciones en los destructores nunca son útiles por una simple razón: los destruidores destruyen objetos que el código de ejecución ya no necesita. Cualquier error que ocurra durante su desasignación se puede manejar de forma segura de manera independiente del contexto, como iniciar sesión, mostrar al usuario, ignorar o llamar al std::terminate. Al código circundante no le importa porque ya no necesita el objeto. Por lo tanto, no es necesario propagar una excepción a través de la pila y cancelar el cálculo actual.

En su ejemplo, fp podría insertarse con seguridad en una cola global de archivos no cerrables y manejarse más tarde. El código de llamada puede continuar sin problemas.

Según este argumento, los destructores muy rara vez tienen que lanzar. En la práctica, realmente rara vez lanzan, lo que explica el uso generalizado de RAII.

Answer 7

Quiero incluir algunas ideas más sobre "RAII" vs. GC. Los aspectos de usar algún tipo de cierre, destrucción, finalización, cualquiera que sea la función ya se explican como es el aspecto de la liberación determinística de recursos.Hay, al menos, dos instalaciones más importantes que se habilitan mediante el uso de destructores y, por lo tanto, hacer el seguimiento de los recursos de una manera controlada programador:

1. En el mundo RAII que es posible tener un puntero rancio, es decir, un puntero que apunta a un objeto ya destruido. Lo que parece ser una cosa mala realmente permite que los objetos relacionados se ubiquen muy cerca en la memoria. Incluso si no encajan en la misma línea de caché, al menos encajarían en la página de memoria. En cierta medida, también podría lograrse una mayor proximidad compactando el recolector de basura, pero en el mundo de C++ esto se produce naturalmente y ya está determinado en tiempo de compilación.
2. Aunque normalmente la memoria se acaba de asignar y liberar utilizando los operadores new y delete es posible asignar memoria, p. Ej. de una agrupación y arregle para un uso de memoria compactador de los objetos que se sabe están relacionados. Esto también se puede usar para colocar objetos en áreas de memoria dedicadas, p. memoria compartida u otros rangos de direcciones para hardware especial.

Aunque estos usos no necesariamente usan las técnicas de RAII directamente, están habilitados por el control más explícito sobre la memoria. Dicho esto, también hay usos de memoria en los que la recolección de basura tiene una clara ventaja, p. al pasar objetos entre múltiples hilos. En un mundo ideal, ambas técnicas estarían disponibles y C++ está tomando algunas medidas para apoyar la recolección de basura (a veces denominada "recolección de basura") para enfatizar que está tratando de dar una vista de memoria infinita del sistema, es decir, los objetos recolectados no son destruido pero su ubicación de memoria se reutiliza). Las discusiones hasta ahora no siguen la ruta tomada por C++/CLI de usar dos tipos diferentes de referencias y punteros.

Answer 8

Se supone que los destructores son siempre exitosos. ¿Por qué no solo asegurarse de que fclose no fallará?

Siempre puede hacer fflush o alguna otra cosa manualmente y comprobar el error para asegurarse de que fclose tendrá éxito más adelante.