×
Namespaces

Variants
Actions
(Difference between revisions)

Abandonos (Leaves)

From Nokia Developer Wiki
Jump to: navigation, search
cabezonxdg (Talk | contribs)
m (Formatação)
hamishwillee (Talk | contribs)
m (Hamishwillee - Bot addition of Template:ArticleMetaData)
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Abandonos (Leaves) são utilizados ao invés do sistema tradicional de exceções do C++, a principal razão disso é pelo fato dos abandonos serem mais leves, necessitarem de menos linhas de códigos e também por não serem suportados pelo compilador GNU na época em que Symbian OS foi desenvolvido. Abandonos podem ocorrer como resultado de uma condição de erro ou de um evento anormal, como falta de memória ou de espaço em disco (ou falta de espaço no cartão de memória flash) para completar uma operação. O abandono propaga o erro a um local no código onde ele pode ser gerenciado, chamado TRAP harness.
+
{{ArticleMetaData
 +
|sourcecode= <!-- Link to example source code e.g. [[Media:The Code Example ZIP.zip]] -->
 +
|installfile= <!-- Link to installation file (e.g. [[Media:The Installation File.sis]]) -->
 +
|devices= <!-- Devices tested against - e.g. ''devices=Nokia 6131 NFC, Nokia C7-00'') -->
 +
|sdk= <!-- SDK(s) built and tested against (e.g. [http://linktosdkdownload/ Nokia Qt SDK 1.1]) -->
 +
|platform= <!-- Compatible platforms - e.g. Symbian^1 and later, Qt 4.6 and later -->
 +
|devicecompatability= <!-- Compatible devices e.g.: All* (must have internal GPS) -->
 +
|dependencies= <!-- Any other/external dependencies e.g.: Google Maps Api v1.0 -->
 +
|signing=<!-- Signing requirements - empty or one of: Self-Signed, DevCert, Manufacturer -->
 +
|capabilities=<!-- Capabilities required by the article/code example (e.g. Location, NetworkServices. -->
 +
|keywords= <!-- APIs, classes and methods (e.g. QSystemScreenSaver, QList, CBase -->
 +
|id= <!-- Article Id (Knowledge base articles only) -->
 +
|language=Lang-Portuguese
 +
|translated-by= <!-- [[User: XXXXX]] -->
 +
|translated-from-title=<!-- Title only -->
 +
|translated-from-id= <!-- Id of translated revision -->
 +
|review-by=<!-- After re-review: [[User:username]] -->
 +
|review-timestamp=<!-- After re-review: YYYYMMDD -->
 +
|update-by=<!-- After significant update: [[User:username]]-->
 +
|update-timestamp=<!-- After significant update: YYYYMMDD -->
 +
|creationdate=20070527
 +
|author=[[User:Cabezonxdg]]
 +
}}[[Category:Symbian C++]]
 +
== Introdução ==
 +
Um código em Symbian é dito que abandona quando um erro em tempo de execução ocorre. Abandonos fazem parte do mecanismo próprio de exceção implementado pelo c++ para Symbian OS, eles seriam análogos ao <tt>throw</tt> de c++ padrão e são utilizados no lançamento de exceções.  
  
<br>
+
Segundo a conveção de nomes adotada pelo SymbianC++ funções que abandonam tem seu nome terminado por L indicando ao quem usá-las que tal função pode abandonar. Uma função ao abandonar emite um código de erro indicando o motivo pelo qual a operação falhou.
  
== TRAP Harness ==
+
Funções podem abandonar se:
  
Para contornar a falta do sistema de exceção padrão foram desenvolvidas as funções TRAP e TRAPD que podem ser consideradas como alternativas ao Try/Catch (apesar de sua implementação interna no Symbian v9.0 ser feita utilizando Try/Catch). Na ocorrência de um abandono , ele será propagado até que seja capturado por uma TRAP. Caso a TRAP não seja implementada pelo programador o abandono será capturado pelo TRAP do FrameWork e o SO irá tomar as precauções necessárias (exibir uma dialog com o motivo do abandono por exemplo). No entando em algumas ocasiões o programador necessita gerenciar de forma particular um abandono e então fazemos o uso da função TRAP.<br>
+
* Fizerem chamadas a outras funções que abandonam fora de uma <tt>TRAP</tt>;
 +
* Chamando uma das funções do sistema utilizadas para lançar abandonos, exemplo: <tt>User::Leave()</tt>;
 +
* Fizerem uso do operador sobrecarregado <tt>new</tt>.
  
Trap é uma função inline definida no cabeçalho e32cmn.h e pode ser definida como:<br>
+
[[Category:Lang-Portuguese]][[Category: Essential Idioms]]
 
+
TRAP(_r, _s);
+
 
+
Esta função executa um conjunto de instruções C++ e retorna um inteiro com o valor do abandono (caso tenha ocorrido).<br>
+
 
+
Onde:<br>
+
 
+
_r = O código de abandono gerado pelas funções é salvo neste inteiro. Este inteiro precisa ser declarado antes de usar a TRAP.<br>
+
 
+
_s = Conjunto de instruções C++ que serão colocadas "a prova" utilizando a TRAP. Caso estas abandonem o valor é passado para _r.
+
 
+
Uma alternativa à TRAP é o TRAPD, utilizado apenas por conveniência onde o inteiro que recebe o código de abandono não precisa ser declaro explicitamente.
+
 
+
<br>
+
 
+
Exemplos de uso do TRAP:
+
 
+
 
+
<code cpp="cpp">TInt err;
+
TRAP(err, FuncaoQuePodeAbandonarL());
+
if( err == KErrNone ) // não ocorreu abandono
+
{
+
      // faz algo
+
}
+
else // Ocorreu abandono
+
{
+
        // faz algo
+
}</code>
+
 
+
 
+
Exemplo com TRAPD:
+
 
+
 
+
<code cpp="cpp">TRAPD(err, FuncaoQuePodeAbandonarL());
+
if( err == KErrorNone )
+
{
+
        // faz algo
+
}
+
else
+
{
+
        // faz algo
+
}</code>
+
 
+
 
+
'''Nota:''' A utilização de TRAPS na aplicação aumenta significamente o tamanho do código final e causa um certo overhead, então deve ser utilizado com cautela.
+
 
+
== Pilha de limpeza ==
+
 
+
Considere o seguinte código:<br>
+
 
+
<br>
+
<code cpp="cpp">void CMinhaClasse::CarregarAlgoL()
+
{
+
        CCarro* fiat = new (ELeave) CCarro();
+
        fiat->DirigirL();
+
        delete fiat;
+
}
+
</code>
+
 
+
 
+
<br> <br> <br> <br> É feita a alocação dinâmica de um objeto do tipo CCarro e então este objeto chama o método DirigirL. Este método pode lançar uma exceção - ''Métodos que possam lançar exceção terminam com L'' - , caso uma exceção ocorra todas as variáveis automáticas do método CarregarAlgoL serão removidas incluindo neste caso o ponteiro fiat. Isto acontecendo perderemos a referência para a memória que fiat aponta - ''quando ocorre uma exceção não há garantia que o destrutor da classe será chamado ou que os códigos seguintes serão executados''-&nbsp; no exemplo, o comando delete nunca será executado. O resultado seria um vazamento de memória. Pode parecer que alguns bytes não representam muita coisa, mas para um sistema com recursos limitados e que não faz re-boot frequentemente isto pode ocasionar sérios problemas.<br>
+
 
+
Para resolver problemas como este foi desenvolvido o mecanismo de limpeza da pilha ( CleanupStack ). Considere o seguinte código:<br>
+
 
+
<br>
+
<code cpp="cpp">void CMinhaClasse::CarregarAlgoL()
+
{
+
        CCarro* fiat = new (ELeave) CCarro();
+
        CleanupStack::PushL( fiat );
+
        fiat->DirigirL();
+
        CleanupStack::PopAndDestroy();
+
}</code>
+
<br>Caso não tenha notado, foram adicionadas duas linhas de código que representam chamadas à métodos de CleanupStack. Neste código, caso DirigirL abandone não perderemos a referência a memória que fiat aponta. Seu uso é bastante simples, você adiciona ponteiros automáticos à pilha e na ocorrência de um abandono será chamado o destrutor do objeto que este ponteiro aponta e então sua memória será liberada através do operador User::Free.
+
 
+
 
+
 
+
<br>
+
 
+
<br>
+
 
+
<br>
+
 
+
<br>
+
 
+
A classe CleanupStack possui apenas&nbsp; 4 métodos (com suas devidas sobrecargas) todos são estáticos e bastante intuítivos.<br>
+
 
+
'''PushL'''- Adiciona um ponteiro a pilha de limpeza.
+
 
+
'''Pop'''- Remove um ponteiro da pilha de limpeza
+
 
+
'''PopAndDestroy'''- Remove um ponteiro da pilha de limpeza e libera sua memória. O mesmo que realizar um CleanupStack::Pop() e então delete.
+
 
+
<br>
+
 
+
'''''Nota 1''''': PushL pode gerar um abandono mas está fora do escopo deste artigo discutir isto, para maior informações consulte [1].
+
 
+
'''''Nota 2''''': Atributos membros de classe não devem ser adicionados a pilha de limpeza pois é função da sua classe realizar a deleção. Sendo colocado na pilha de limpeza poderia ocorrer uma dupla deleção o que pode ocasionar problemas.
+
 
+
== Construção em duas fases ==
+
 
+
Construtores e destrutores não podem retornar um valor e por isso não pode abandonar. Pensando nisso, foi desenvolvido a contrução em duas fases para evitar que construtores gerem abandonos. Funções que possam gerar um abandono devem ser chamadas no ConstructL (L no final é uma convenção de nome que significa que essa função pode abandonar) ao invés do construtor padrão C++. Qualquer outra inicialização que não possa abandonar pode ser inicializada normalmente no construtor padrão.
+
 
+
Exemplo:
+
 
+
<br>
+
<code cpp="cpp">void CMinhaAplicao::ConstructL(const TRect& aRect)
+
{
+
    CMinhaAplicacao* self = CMinhaAplicacao(aRect);
+
    CleanupStack::PushL(self);
+
    self->ConstructL(aRect) ;
+
    CleanupStack::Pop(self);
+
    return self;
+
}
+
 
+
CMinhaAplicacao::CMinhaAplicacao()
+
{
+
    iVariavel = 1;
+
}
+
</code>
+
 
+
 
+
<br> <br> <br> <br> <br>
+
 
+
== Leitura complementar ==
+
 
+
[[Pilha de limpeza - Cleanup Stack|[1] - Pilha de limpeza - Cleanup Stack]]<br> [[Construtor em 2 fases]]<br> [[Gerência de memória]]<br>
+
 
+
[[Category:Lang-PT]] [[Category:Symbian_C++_(Português)]]
+

Latest revision as of 07:06, 10 November 2011

Article Metadata

Artigo
Criado por cabezonxdg em 27 May 2007
Última alteração feita por hamishwillee em 10 Nov 2011

[edit] Introdução

Um código em Symbian é dito que abandona quando um erro em tempo de execução ocorre. Abandonos fazem parte do mecanismo próprio de exceção implementado pelo c++ para Symbian OS, eles seriam análogos ao throw de c++ padrão e são utilizados no lançamento de exceções.

Segundo a conveção de nomes adotada pelo SymbianC++ funções que abandonam tem seu nome terminado por L indicando ao quem usá-las que tal função pode abandonar. Uma função ao abandonar emite um código de erro indicando o motivo pelo qual a operação falhou.

Funções podem abandonar se:

  • Fizerem chamadas a outras funções que abandonam fora de uma TRAP;
  • Chamando uma das funções do sistema utilizadas para lançar abandonos, exemplo: User::Leave();
  • Fizerem uso do operador sobrecarregado new.
This page was last modified on 10 November 2011, at 07:06.
115 page views in the last 30 days.
×