c++ - programacion - Fuga de memoria: suelte y elimine

recoleccion de basura en programacion

Question

IFSUPCUTILSize* size = NULL;
CoCreateInstance(CLSID_UTILSize, NULL, CLSCTX_INPROC_SERVER, IID_IFSUPCUTILSize,    reinterpret_cast<void**>(&size));

if (size != NULL){
size->Release();
size = NULL;
}
delete size;

¿Necesito "borrar tamaño" en el código de arriba? Si incluyo "eliminar tamaño", tendré una pérdida de memoria porque no utilicé Nuevo. O hay un nuevo dentro de la llamada a CoCreateInsatnce. Construyo esto con VC ++ 6.

Answer 1

Desde una perspectiva C ++, lo que estás haciendo está bien. Llamar a eliminar en un puntero nulo no es operativo. Sin embargo, es innecesario.

Desde una perspectiva de VC ++ 6, no puedo decir, es notoriamente no conforme. No puedo imaginar por qué podría ser un problema. Pero, de nuevo, es ciertamente innecesario.

Definitivamente no invoque eliminar en este puntero antes de establecerlo en NULL. No asignó con nuevo, así que no llame a eliminar. La gestión de recursos aquí está a cargo de las funciones COM.

Answer 2

Las interfaces COM son referencias contadas. CoCreateInstance() devuelve un puntero de interfaz a un objeto COM cuyo recuento de referencias ya se ha incrementado. La Release() llamada Release() disminuye el recuento de referencia. Cuando el recuento de referencias cae a cero, el objeto COM se libera automáticamente. ¡NO invoque delete en un puntero de interfaz COM! Use siempre Release() solamente.

Answer 3

Supongo que size-> Release () está liberando recursos del sistema operativo (manejadores de archivos, etc.). Por lo tanto, coloque el tamaño de eliminación inmediatamente después de establecer el tamaño en nulo.

Answer 4

Si incluyo "eliminar tamaño", tendré una pérdida de memoria porque no utilicé Nuevo.

Por lo general, no obtendrá una pérdida de memoria al llamar a delete . Puede y muchas veces obtendrá corrupción de memoria. Los dos son muy diferentes: una pérdida de memoria significa que su programa retiene la memoria que en realidad no utiliza; con el tiempo, el programa podría fallar si la memoria filtrada continúa creciendo; la corrupción en la memoria significa que de alguna manera destruyó importantes estructuras de contabilidad en la memoria, y es probable que se bloquee muy pronto (al menos debe esperar un choque, la alternativa es peor). Una causa muy común de corrupción de memoria es la desasignación de la memoria con la rutina incorrecta , especialmente en Windows (es una tradición redefinir malloc y free en UNIX, por lo que los sistemas UNIX a menudo se esfuerzan para asegurarse de que sea posible hacerlo ) .

O hay un nuevo dentro de la llamada a CoCreateInstance

Lo que está dentro de CoCreateInstance debe ser manejado por Release() . Por lo menos, nunca debe desasignar la memoria solo porque tenga un puntero. Necesita saber cómo se asignó la memoria para desasignarlo correctamente.

Answer 5

Nunca intente utilizar delete para lanzar servidores COM implementados por otro módulo (ese es su caso).

1. No siempre se sabe si ese servidor está escrito en C ++. Hacer delete en un objeto que no sea de C ++ es un comportamiento indefinido.
2. Incluso si el servidor está escrito en C ++, no se sabe en qué montón se asignó y si delete desasignará la memoria correctamente o desencadenará un comportamiento indefinido.
3. Llama a delete en un puntero de interfaz declarado como no tener un destructor virtual, es un comportamiento indefinido.
4. No siempre sabrá si le han servido un objeto real o un proxy. Hacer delete en un proxy es un comportamiento indefinido.
5. Una vez que haya llamado a Release() el objeto ya se haya borrado automáticamente y que volver a delete sea ​​un comportamiento indefinido.
6. Algunos terceros podrían haber tomado posesión del objeto, por ejemplo, una instancia de puntero global podría haber sido configurada para su objeto. Si delete esos otros indicadores, se volverán inestables y eso probablemente causará un comportamiento indefinido más adelante.

En pocas palabras: no use delete en este caso nunca. Call Release() para liberar la propiedad del objeto y eso será suficiente.