c pergunta grátis

Question

Posso fazer isso em 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;

Answer 1

1) Isso depende do contrato que você tem com some_func().Se some_func espera que você chame free() em seu valor de retorno, seu código está ok.

2) Não há problema, embora não seja muito elegante, em reutilizar variáveis ​​em C.Geralmente é melhor usar variáveis ​​diferentes para finalidades diferentes.Do ponto de vista do desempenho e do uso de memória, é completamente a mesma coisa.

Answer 2

Isso depende do que some_func() está fazendo. Se estiver alocando memória com malloc(), então você deveria free() quando você terminar. Se não for, então você não deve. Consulte a documentação da função, com certeza.

Answer 3

Eu segundo a resposta de Edgar, mas também observe que o teste para nulo aqui não é desnecessário:

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

Porque o livre (nulo) é permitido.

Answer 4

Seu código parece bom - qual bit específico você está perguntando? Mas observe que, se a função retornar um int *, não há necessidade de um elenco e, se não o fizer, você provavelmente não deve atribuí -lo a um int *.

Answer 5

Bem, o único problema que vejo é o problema de legibilidade não vinculado apenas a C. Você reutilizou um nome variável tantas vezes em um bloco que é realmente difícil descobrir o que é usado.

Answer 6

Se algum_func retornar um ponteiro que aponta para uma memória alocada dinamicamente, sim.

Answer 7

Tudo bem, desde que algum_func () faça o que deveria fazer. Se atribuir um endereço inválido (não alocado) a I, fará com que seu programa trave.

Answer 8

Depende do contrato de Some_Func ().

Se Some_func () aloca alguma memória e designa de sua responsabilidade liberá -la, então sim, tudo bem para libertá -lo. De fato, é um bug não para.

Este é um dos insetos de trabalho em um idioma não gerenciado, você deve acompanhar quais recursos você possui e certifique -se de liberá -los.

Answer 9

Se some_func() "possui" seus dados e retorna apenas ponteiros para você inspecionar, você não deve libertá -los. Se isso mallocS apenas para você, então você é realmente responsável por fazer o free

Answer 10

Em seu primeiro passo

int *i;
// do stuff

i = NULL;

Se eu apontei para algo que alocou a memória, essa memória não será perdida para sempre (vazamento de memória)?

Por exemplo:

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

deixaria um pedaço de memória do tamanho de int deixado flutuando no éter.

O mesmo vale para os seus exemplos de algum_func (), mas acho que você está testando corretamente para tentar liberar o que quer que algum_func () deixasse para trás. Especialmente se você não souber como alguém () funciona.

Se algum_func () for de uma biblioteca, pode haver uma função free_some_func (i) que faria o trabalho para você.

Answer 11

i = (int *) some_func();

Você não disse o que o tipo de retorno de some_func() é, mas o (int *) A parte é um pouco suspeita. C geralmente é bastante branda sobre essas coisas e geralmente compila de maneira limpa, sem a necessidade de um elenco explícito. Caso contrário, considere cuidadosamente se o que você está fazendo é tão bem definido e portátil como você gostaria.

Answer 12

@Kevin Montrose: Hmmm.yeah, exigindo que os programadores sejam competentes é um verdadeiro intervalo. Talvez todos devêssemos usar capacetes enquanto tocamos o código, para o caso do teto entrar. E qual é o "contrato" de some_func? some_func Ou retorna um valor adequado para passar para gratuitamente, ou não. Não há "contrato" lá. Mas então, sou um peido velho e não acredito na ofuscação para ganhar pontos de brownie com a gerência. Estes são conceitos simples.

@CAF: Provavelmente é compilador/dependente da biblioteca. É mais seguro verificar como ele está fazendo. Só porque sua implementação de cheques gratuitos para um ponteiro nulo não significa que todos eles o fazem.

Answer 13

Se você quer dizer que não há problema em reutilizar o ponteiro int, em vez de declarar um novo a cada uso, com certeza está tudo bem, mas em geral pode ser confuso se todo o seu // do stuff consiste em muito código. Outro programador pode ficar confuso sobre onde *i veio de e por que significa x aqui e y.