- Olvídese de la recolección de basura (use RAII en su lugar). Tenga en cuenta que incluso el recolector de basura también puede filtrarse (si olvida "anular" algunas referencias en Java / C #), y que el recolector de basura no lo ayudará a deshacerse de los recursos (si tiene un objeto que adquirió un identificador para un archivo, el archivo no se liberará automáticamente cuando el objeto se salga del alcance si no lo hace manualmente en Java, o si usa el patrón "desechar" en C #).
- Olvídese de la regla de "un retorno por función" . Este es un buen consejo de C para evitar fugas, pero está desactualizado en C ++ debido a su uso de excepciones (use RAII en su lugar).
- Y aunque el "Patrón Sandwich" es un buen consejo de C, está desactualizado en C ++ debido a su uso de excepciones (use RAII en su lugar).
Esta publicación parece ser repetitiva, pero en C ++, el patrón más básico para saber es RAII .
Aprenda a usar punteros inteligentes, tanto desde boost, TR1 o incluso el auto_ptr bajo (pero a menudo lo suficientemente eficiente) (pero debe conocer sus limitaciones).
RAII es la base de la seguridad de excepción y la eliminación de recursos en C ++, y ningún otro patrón (sándwich, etc.) le proporcionará ambos (y la mayoría de las veces, no le dará ninguno).
Vea a continuación una comparación de código RAII y no RAII:
void doSandwich()
{
T * p = new T() ;
// do something with p
delete p ; // leak if the p processing throws or return
}
void doRAIIDynamic()
{
std::auto_ptr<T> p(new T()) ; // you can use other smart pointers, too
// do something with p
// WON'T EVER LEAK, even in case of exceptions, returns, breaks, etc.
}
void doRAIIStatic()
{
T p ;
// do something with p
// WON'T EVER LEAK, even in case of exceptions, returns, breaks, etc.
}
Para resumir (después del comentario de Ogre Psalm33 ), RAII se basa en tres conceptos:
- Una vez que se construye el objeto, ¡simplemente funciona! Adquirir recursos en el constructor.
- ¡La destrucción de objetos es suficiente! Haz recursos gratis en el destructor.
- ¡Se trata de ámbitos! Los objetos de ámbito (ver el ejemplo doRAIIStatic anterior) se construirán en su declaración, y se destruirán en el momento en que la ejecución salga del ámbito, sin importar cómo salga (retorno, interrupción, excepción, etc.).
Esto significa que en el código C ++ correcto, la mayoría de los objetos no se construirán newy se declararán en la pila. Y para aquellos construidos usando new, todos tendrán un alcance (por ejemplo, conectado a un puntero inteligente).
Como desarrollador, esto es muy poderoso, ya que no tendrá que preocuparse por el manejo manual de recursos (como se hace en C, o para algunos objetos en Java que hacen un uso intensivo de try/ finallypara ese caso) ...
Editar (2012-02-12)
"los objetos con alcance ... serán destruidos ... sin importar la salida", eso no es del todo cierto. Hay formas de engañar a RAII. cualquier sabor de terminar () omitirá la limpieza. exit (EXIT_SUCCESS) es un oxímoron en este sentido.
- Wilhelmtell
Wilhelmtell tiene toda la razón al respecto: hay formas excepcionales de engañar a la RAII, todo lo cual lleva a que el proceso se detenga abruptamente.
Esas son formas excepcionales porque el código C ++ no está lleno de terminación, salida, etc., o en el caso de excepciones, queremos una excepción no controlada para bloquear el proceso y volcar su imagen de memoria como está, y no después de la limpieza.
Pero aún debemos conocer esos casos porque, aunque rara vez suceden, aún pueden suceder.
(¿quién llama terminateo exiten código C ++ casual? ... Recuerdo haber tenido que lidiar con ese problema cuando jugaba con GLUT : esta biblioteca está muy orientada a C, yendo tan lejos como a diseñarla activamente para dificultar las cosas a los desarrolladores de C ++ como no preocuparse sobre la asignación de datos asignados , o tener decisiones "interesantes" sobre no volver nunca de su ciclo principal ... no comentaré sobre eso) .