- Esqueça a coleta de lixo (use RAII). Observe que até o Garbage Collector também pode vazar (se você esquecer de "anular" algumas referências em Java / C #), e que o Garbage Collector não ajudará a descartar recursos (se você tiver um objeto que adquiriu um identificador para um arquivo, o arquivo não será liberado automaticamente quando o objeto ficar fora do escopo se você não o fizer manualmente em Java ou usar o padrão "dispor" em C #).
- Esqueça a regra "um retorno por função" . Este é um bom conselho de C para evitar vazamentos, mas está desatualizado no C ++ devido ao uso de exceções (use RAII).
- E embora o "Padrão de sanduíche" seja um bom conselho de C, ele está desatualizado no C ++ devido ao uso de exceções (use RAII).
Este post parece ser repetitivo, mas em C ++, o padrão mais básico a ser conhecido é o RAII .
Aprenda a usar ponteiros inteligentes, tanto do boost, TR1 quanto do auto_ptr modesto (mas geralmente eficiente o suficiente) (mas você deve conhecer suas limitações).
RAII é a base da segurança de exceção e do descarte de recursos em C ++, e nenhum outro padrão (sanduíche, etc.) fornecerá os dois (e na maioria das vezes, não fornecerá nenhum).
Veja abaixo uma comparação do código RAII e não-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 (após o comentário do Ogre Psalm33 ), o RAII se baseia em três conceitos:
- Uma vez que o objeto é construído, ele simplesmente funciona! Adquira recursos no construtor.
- Destruição de objetos é suficiente! Libere recursos no destruidor.
- É tudo sobre escopos! Objetos com escopo definido (veja o exemplo doRAIIStatic acima) serão construídos na declaração e serão destruídos no momento em que a execução sair do escopo, independentemente da saída (retorno, interrupção, exceção, etc.).
Isso significa que, no código C ++ correto, a maioria dos objetos não será construída newe, em vez disso, será declarada na pilha. E para aqueles construídos usando new, tudo terá um escopo de alguma forma (por exemplo, anexado a um ponteiro inteligente).
Como desenvolvedor, isso é muito poderoso, pois você não precisará se preocupar com o manuseio manual de recursos (como em C ou em alguns objetos em Java que fazem uso intensivo try/ finallypara esse caso) ...
Editar (12-02-2012)
"objetos com escopo ... serão destruídos ... não importa a saída", isso não é inteiramente verdade. existem maneiras de enganar RAII. qualquer sabor de terminate () ignorará a limpeza. exit (EXIT_SUCCESS) é um oxímoro a esse respeito.
- wilhelmtell
wilhelmtell está certo sobre isso: existem maneiras excepcionais de enganar a RAII, todas levando à parada abrupta do processo.
Essas são maneiras excepcionais porque o código C ++ não está repleto de terminação, saída etc., ou, no caso de exceções, queremos uma exceção não tratada para travar o processo e o core despejar sua imagem de memória como está, e não após a limpeza.
Mas ainda precisamos saber sobre esses casos, porque, embora raramente aconteçam, ainda podem acontecer.
(quem chama terminateou exitno código C ++ casual? ... Lembro-me de ter que lidar com esse problema ao jogar com o GLUT : essa biblioteca é muito orientada para C, chegando ao ponto de projetá-la ativamente para tornar as coisas difíceis para desenvolvedores de C ++, como não se importarem sobre empilhar dados alocados ou tomar decisões "interessantes" sobre nunca retornar do loop principal ... Não vou comentar sobre isso) .