Tuesday, February 17, 2009

leaves and traps..... (II)

How to work with leaves

We assume that a function has previously allocated memory on the heap and this memory is pointed to by a local pointer variable. Now,if a leave occurs within that function then ,that pointer will be destroyed by the Leave (As Leave unwinds the stack frame upto the TRAP macro). Lets see,


Eventually the memory pointed to by "test" variable is unallocated and will result in a memory leak.
How to prevent this?

If we have to use any local variable which point to heap objects, we must push the variable to the CleanupStack before calling any function that may leave.

Important Note:
1. Member variables are leave-safe
2.Neither a constructor nor a destructor should contain code that may
leave, since doing so would potentially leak memory.

Leaves Vs Panics

1. Leaves occur in exceptional conditions (Out of memory or Out of disk conditions). Leaves should be handled properly to continue the normal flow of execution. Leaves do not terminate the normal flow of execution. On the other hand, Panics cannot be caught and handled.

2. Leaves occur at program runtime due to exception situation. Panics , on the other hand occur at the development time. If they occur at runtime, they cannot be fixed. So, the cause pf panics should be searched and fixed at development period.

Leaves and traps (I)

How funny this should sound to a Symbian C++ programmer? Till now, I do not have a clear idea on Leave and Trap mechanism of Symbian OS. Anyways, better let than never!! Here are some informations that I found essential to know about Leave - Trap mechanism of Symbian C++.

BASICS
1. Standard C++ exception handling mechanism adds substantially to the size of compiled code and RAM overheads (irrespective of whether the exceptions are thrown or not). That is why Symbian OS introduced the Leave - Trap mechanism. Before Symbian OS version 9 , the standars C++ exception handling were disabled in compilers so that any call to try catch or throw would result in a compilation error.But in Symbian OS 9, the standars C++ is supported (Hurrah!!!!).

2. The Leave - Trap mechanism is an alternative to standard C++ exception and conventional error checking. In other words, Leave- Trap constitutes to lightweight error handling of Symbian OS.

3. a "leave" (i.e. User::Leave() or User::LeaveifError()) suspends the code execution at the point where the leave occurs and resumes the execution at the point where the "leave" is "Trap"ped. The trap harness in Symbian is actually a "TRAP" macro. The "leave" sets the stack pointer to the context of the "TRAP" and jumps to that location.

4. User::Leave() or User::LeaveIfError() ---- Throw
TRAP ------------------------------------- try + catch

5. Critical Information on Leave:
Unlike C++ throw, a Leave will simply deallocate objects on the stack - it does not call the descriptor of that object. So, if a stack object owns a resource which must be deallocated or released as a part of destruction, that resource is not released if a leave occurs. That is why we have a class naming convention of Symbian OS which clearly states which kinds of classes can be instantiated and used safely on the stack (T classes). So, only a stack based T class will be cleaned up correctly if a Leave occurs (because there is nothing of an object of T class in any place other than stack).

6.R classes may also be created on the stack, but they must be made ‘‘leave safe’’, if used in functions that may leave, by using the cleanup stack.

new(ELeave)

1. The overloaded new operator which takes ELeave as a parameter guarantees that the pointer return value will be valid if a Leave is not occured in the constructor. Use of this overload allows the pointer to be used without further test that the allcation was successful(The allocation would leave if it were not successful).