Pregunta

¿Está bien hacer esto en c?

int *i;
// do stuff

i = NULL;

i = (int *) some_func();
// do stuff

if (i != NULL)
    free(i);

i = NULL;

// do stuff
i = (int *) some_func();
// do stuff
if (i != NULL)
    free(i);

i = NULL;
¿Fue útil?

Solución

1) Eso depende del contrato que tengas con some_func (). Si some_func espera que llame a free () en su valor de retorno, su código es correcto.

2) Está bien, aunque no es terriblemente elegante, reutilizar las variables en C. Generalmente es mejor usar diferentes variables para diferentes propósitos. Desde una perspectiva de rendimiento y uso de memoria, es completamente lo mismo.

Otros consejos

Eso depende de lo que some_func () está haciendo. Si está asignando memoria con malloc () , entonces debería liberar () cuando haya terminado. Si no lo es, entonces no deberías. Consulte la documentación de la función para estar seguro.

Respaldé la respuesta de Edgar, pero también noté que la prueba para NULL aquí es innecesaria:

if (i != NULL)
    free(i);

porque se permite gratis (NULL).

Tu código se ve bien. ¿Qué bit específico estás preguntando? Pero tenga en cuenta que si la función devuelve un int *, no hay necesidad de un lanzamiento, y si no lo hace, probablemente no debería asignarlo a un int *.

Bueno, el único problema que veo es que el problema de legibilidad no está vinculado solo a C. Reutilizó un nombre de variable tantas veces en un bloque que es realmente difícil saber para qué se usa.

Si some_func devuelve un puntero que apunta a una memoria asignada dinámicamente, sí.

Está bien siempre que some_func () haga lo que se supone que debe hacer. Si asigna una dirección no válida (no asignada) a i, su programa se bloqueará.

Depende del contrato de some_func ().

Si some_func () asigna algo de memoria y le asigna la responsabilidad de liberarlo, entonces está bien liberarlo (). De hecho, es un error no hacerlo.

Este es uno de los problemas de trabajar en un lenguaje no administrado, debes hacer un seguimiento de los recursos que tienes y asegurarte de liberarlos.

Si some_func () " posee " sus datos y solo le devuelve los punteros para que los inspeccione, no debe liberarlos. Si los datos de malloc son solo para usted, entonces usted es responsable de hacer el free

En tu primer paso

int *i;
// do stuff

i = NULL;

Si señalé algo que asignó memoria, ¿no se perderá esa memoria para siempre (pérdida de memoria)?

Por ejemplo:

int *i;
i = (int*) malloc(sizeof(int);
i = NULL;

dejaría un trozo de memoria del tamaño de int dejado flotando en el éter.

Lo mismo es cierto para los ejemplos de some_func (), pero creo que estás probando correctamente para intentar liberar lo que some_func () haya dejado atrás. Especialmente si no sabes cómo funciona some_func ().

Si some_func () es de una biblioteca, puede haber una función free_some_func (i) que haría el trabajo por usted.

  

i = (int *) some_func ();

No dijiste cuál es el tipo de retorno de some_func () , pero la parte (int *) es un poco sospechosa. En general, C es bastante indulgente con respecto a estas cosas y, por lo general, compila limpiamente sin la necesidad de un reparto explícito. Si no es así, considere cuidadosamente si lo que está haciendo está tan definido y portátil como le gustaría que fuera.

@Kevin Montrose: Hmmm. Sí, requerir que los programadores sean competentes es un verdadero factor decisivo. Tal vez deberíamos usar cascos mientras lanzamos el código, en caso de que se caiga el techo. ¿Y cuál es el "contrato"? de some_func ? some_func devuelve un valor adecuado para pasar a free, o no lo hace. No hay " contrato " ahí. Pero entonces, soy un viejo pedo, y no creo en la ofuscación para ganar puntos brownie con la administración. Estos son conceptos simples.

@caf: esto es probablemente compilador / dependiente de la biblioteca. Es más seguro comprobar que está haciendo. Solo porque su implementación de comprobaciones gratuitas para un puntero NULL no significa que todas lo hagan.

Si quiere decir, ¿está bien reutilizar el puntero int en lugar de declarar uno nuevo con cada uso? de mucho codigo. Otro programador podría confundirse sobre de dónde proviene * i y por qué significa X aquí e Y allí.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top