Categories: Symbian C++ (Português) | Lang-PT

This page was last modified 15:34, 26 October 2007.

From Forum Nokia Wiki

Como visto na Gerência de memória os recursos no Symbian são tratados com bastante cuidado pois não podem ser disperdiçados, temos mecanismos como os Abandonos - Leaves e a Pilha de limpeza - Cleanup Stack que procuram evitar que isto ocorra.

Brechas na memória ocorrem quando um ponteiro fica orfão, a referência a este ponteiro é perdida e a memória que ele alocou também. Imagine o seguinte código:

CMyApp* self = new (ELeave) CMyApp;
self->ConstructL();

Caso a chamada a ConstructL (note o 'L' de Leave, informando que esta função pode gerar um abandono) falhe, perderemos a referência a memória apontada por self e não poderemos acessar este espaço. Para resolver isso foi criada a Pilha de limpeza. Ao colocar um ponteiro (apenas ponteiros locais) no topo da pilha, você poderá executar métodos que possam gerar abandonos, pois caso um ocorra a pilha irá gerênciar a remoção dos recursos alocados por esse ponteiro.

// Nova construção com CleanupStack
CMyApp* self = new (ELeave) CMyApp;
CleanupStack::PushL(self)
self->ConstructL();
CleanupStack::Pop(self);

Após executar as funções que possam gerar abandonos o ponteiro deve ser removido da pilha.

Algumas regras no manuseio da heap:

Regras para manipulação de recursos

Regra 1

Ponteiros locais que reservem memória dinâmicamente devem ser colocados na pilha de limpeza caso façam chamadas à métodos que possam gerar abandonos. Caso seja gerado um abandono esses ponteiros terão seus recursos desalocados e o ponteiro deletado. Objetos colocados na pilha de limpeza devem ser retirados antes de destruídos.

ex.:

CMyApp* self = CMyApp;
CleanupStack::PushL(self);
// Função que pode gerar um abandono
self->ConstructL();
CleanupStack::Pop(self);

Regra 2

Membros de dados (dados da instância de uma classe) nunca devem ser colocados na pilha de limpeza. Membros de dados devem SEMPRE ser deletadas no destrutor da classe que o contêm. Por convenção de nomes eles começam com 'i'

ex.:

// Código errado!
CleanupStack::PushL(iMembrodedado);
// Membros de dados nunca devem ir para pilha de limpeza

Regra 3

Construtores padrão C++ não podem abandonar. Instruções que podem abandonar devem ser chamadas no construtor de duas fases: ConstructL().

ex.:

// Código errado!
CMyApp::CMyApp()
{
      iGrid = new (ELeave) CAknGrid;
}

Se uma falha ocorresse durante essa alocação teriamos uma brecha na memória e seria gerado um abandono, por isso Construtores C++ não podem chamar métodos que possam abandonar.

// Código correto
void CMyApp::ConstructL()
{
     iGrid = new (ELeave) CAknGrid;
}
== Regra 4 ==
Após deletar o ponteiro de um objeto, é preciso zera-lo antes de sua re-alocação.
 
<code cpp>
void CMyAppAppView::AjustarEndereco(const TDesc& aEndereço)
{
     if(iEndereço)
     {
            delete iEndereço;
            iEndereço = NULL;
     }
     iEnderelo = aEndereço.AllocL();
}
 
Assim como é uma boa forma de programação sempre que ao criar um ponteiro inicializá-lo como NULL.
 
Nota: Não é '''necessário''' setar um ponteiro como NULL quando ele for destruído no destrutor da classe.