É seguro excluir um ponteiro vazio?

Suponha que eu tenha o seguinte código:

void* my_alloc (size_t size)
{
   return new char [size];
}

void my_free (void* ptr)
{
   delete [] ptr;
}

Isso é seguro? Ou deve ptrser convertido para char*antes da exclusão?

Depende de "seguro". Geralmente funciona porque as informações são armazenadas junto com o ponteiro sobre a alocação em si, de modo que o desalocador pode retorná-lo ao lugar certo. Nesse sentido, é "seguro", desde que seu alocador use tags de limite interno. (Muitos fazem.)

No entanto, conforme mencionado em outras respostas, excluir um ponteiro void não chamará destruidores, o que pode ser um problema. Nesse sentido, não é "seguro".

Não há nenhuma boa razão para fazer o que você está fazendo da maneira que está fazendo. Se você deseja escrever suas próprias funções de desalocação, pode usar modelos de função para gerar funções com o tipo correto. Um bom motivo para fazer isso é gerar alocadores de pool, que podem ser extremamente eficientes para tipos específicos.

Conforme mencionado em outras respostas, esse é um comportamento indefinido em C ++. Em geral, é bom evitar comportamentos indefinidos, embora o assunto em si seja complexo e repleto de opiniões conflitantes.

A exclusão por meio de um ponteiro nulo não é definida pelo padrão C ++ - consulte a seção 5.3.5 / 3:

Na primeira alternativa (deletar objeto), se o tipo estático do operando for diferente de seu tipo dinâmico, o tipo estático deve obrigatoriamente ser uma classe base do tipo dinâmico do operando e o tipo estático deve ter um destruidor virtual ou o comportamento é indefinido . Na segunda alternativa (excluir array), se o tipo dinâmico do objeto a ser excluído for diferente de seu tipo estático, o comportamento é indefinido.

E sua nota de rodapé:

Isso implica que um objeto não pode ser excluído usando um ponteiro do tipo void * porque não há objetos do tipo void

.

Não é uma boa ideia e não é algo que você faria em C ++. Você está perdendo suas informações de tipo sem motivo.

Seu destruidor não será chamado nos objetos em seu array que você está excluindo ao chamá-lo para tipos não primitivos.

Em vez disso, você deve substituir new / delete.

Excluir o vazio * provavelmente irá liberar sua memória corretamente por acaso, mas é errado porque os resultados são indefinidos.

Se por algum motivo desconhecido para mim você precisar armazenar seu ponteiro em um vazio * e então liberá-lo, você deve usar malloc e free.

Excluir um ponteiro vazio é perigoso porque os destruidores não serão chamados no valor para o qual ele realmente aponta. Isso pode resultar em vazamentos de memória / recursos em seu aplicativo.

A pergunta não faz sentido. Sua confusão pode ser em parte devido à linguagem desleixada que as pessoas costumam usar comdelete :

Você usa deletepara destruir um objeto que foi alocado dinamicamente. Faça isso, você forma uma expressão de exclusão com um ponteiro para esse objeto . Você nunca "apaga um ponteiro". O que você realmente faz é "deletar um objeto que é identificado por seu endereço".

Agora vemos por que a pergunta não faz sentido: um ponteiro vazio não é o "endereço de um objeto". É apenas um endereço, sem semântica. Ele pode ter vindo do endereço de um objeto real, mas que a informação é perdida, porque foi codificada no tipo do ponteiro originais. A única maneira de restaurar um ponteiro de objeto é lançar o ponteiro void de volta para um ponteiro de objeto (o que requer que o autor saiba o que o ponteiro significa). voidem si é um tipo incompleto e, portanto, nunca o tipo de um objeto, e um ponteiro vazio nunca pode ser usado para identificar um objeto. (Os objetos são identificados em conjunto por seu tipo e endereço.)

Se você realmente deve fazer isso, por que não cortar o homem médio (os newe deleteoperadores) e chamar o mundial operator newe operator deletediretamente? (Claro, se você está tentando instrumentar os operadores newe delete, na verdade deve reimplementar operator newe operator delete.)

void* my_alloc (size_t size)
{
   return ::operator new(size);
}

void my_free (void* ptr)
{
   ::operator delete(ptr);
}

Observe que malloc(), ao contrário , operator newgera std::bad_allocfalha (ou chama o new_handlerse um estiver registrado).

Porque char não tem nenhuma lógica destruidora especial. ISTO não funcionará.

class foo
{
   ~foo() { printf("huzza"); }
}

main()
{
   foo * myFoo = new foo();
   delete ((void*)foo);
}

O d'ctor não será chamado.

Se você deseja usar void *, por que não usa apenas malloc / free? new / delete é mais do que apenas gerenciamento de memória. Basicamente, new / delete chama um construtor / destruidor e há mais coisas acontecendo. Se você apenas usar tipos integrados (como char *) e excluí-los por meio de void *, funcionaria, mas ainda não é recomendado. O resultado final é usar malloc / free se quiser usar void *. Caso contrário, você pode usar funções de modelo para sua conveniência.

template<typename T>
T* my_alloc (size_t size)
{
   return new T [size];
}

template<typename T>
void my_free (T* ptr)
{
   delete [] ptr;
}

int main(void)
{
    char* pChar = my_alloc<char>(10);
    my_free(pChar);
}

Muita gente já comentou dizendo que não, não é seguro deletar um void pointer. Eu concordo com isso, mas também gostaria de acrescentar que se você estiver trabalhando com ponteiros nulos para alocar matrizes contíguas ou algo semelhante, você pode fazer isso newpara poder usar deletecom segurança (com, ahem , um pouco de trabalho extra). Isso é feito alocando um ponteiro vazio para a região de memória (chamado de 'arena') e, em seguida, fornecendo o ponteiro para a nova arena. Consulte esta seção nas Perguntas frequentes sobre C ++ . Esta é uma abordagem comum para implementar pools de memória em C ++.

Dificilmente há uma razão para fazer isso.

Em primeiro lugar, se você não sabe o tipo dos dados, e tudo o que sabe é que são void*, então você realmente deveria tratar esses dados como um blob sem tipo de dados binários ( unsigned char*) e usar malloc/ freepara lidar com eles . Isso é necessário às vezes para coisas como dados de forma de onda e similares, onde você precisa passar void*ponteiros para C apis. Isso é bom.

Se você fazer saber o tipo de dados (ou seja, tem um ctor / dtor), mas por algum motivo você acabou com um void*ponteiro (por qualquer motivo que você tem) , então você realmente deve lançá-lo de volta para o tipo de conhecê-lo para seja , e convoque delete-o.

Usei void *, (também conhecido como tipos desconhecidos) em minha estrutura durante a reflexão de código e outros feitos de ambigüidade e, até agora, não tive problemas (vazamento de memória, violações de acesso, etc.) de nenhum compilador. Apenas avisos devido à operação não ser padrão.

Faz sentido excluir um desconhecido (vazio *). Certifique-se de que o ponteiro segue estas diretrizes ou pode deixar de fazer sentido:

1) O ponteiro desconhecido não deve apontar para um tipo que possui um desconstrutor trivial e, portanto, quando lançado como um ponteiro desconhecido, NUNCA DEVE SER EXCLUÍDO. Exclua o ponteiro desconhecido APÓS colocá-lo de volta no tipo ORIGINAL.

2) A instância está sendo referenciada como um ponteiro desconhecido na memória limite da pilha ou limite da pilha? Se o ponteiro desconhecido fizer referência a uma instância na pilha, ele NUNCA DEVE SER EXCLUÍDO!

3) Você tem 100% de certeza de que o ponteiro desconhecido é uma região de memória válida? Não, então NUNCA DEVE SER DELIMITADO!

Ao todo, há muito pouco trabalho direto que pode ser feito usando um tipo de ponteiro desconhecido (void *). No entanto, indiretamente, o vazio * é um grande recurso para os desenvolvedores C ++ confiarem quando a ambigüidade dos dados é necessária.

Se você quiser apenas um buffer, use malloc / free. Se você deve usar new / delete, considere uma classe de wrapper trivial:

template<int size_ > struct size_buffer { 
  char data_[ size_]; 
  operator void*() { return (void*)&data_; }
};

typedef sized_buffer<100> OpaqueBuffer; // logical description of your sized buffer

OpaqueBuffer* ptr = new OpaqueBuffer();

delete ptr;

Para o caso particular de char.

char é um tipo intrínseco que não possui um destruidor especial. Portanto, os argumentos de vazamento são discutíveis.

sizeof (char) é geralmente um, então também não há argumento de alinhamento. No caso de uma plataforma rara onde o sizeof (char) não é um, eles alocam memória alinhada o suficiente para seu char. Portanto, o argumento do alinhamento também é discutível.

malloc / free seria mais rápido neste caso. Mas você perde std :: bad_alloc e tem que verificar o resultado de malloc. Chamar os novos operadores globais e excluir pode ser melhor, pois ignora o intermediário.