Chapter 1

this line yourself, and then rerun the scenario above. Select New 1, and then exit. The
destructor should ensure heap balance, and the program will exit cleanly.
To summarize, you should only delete objects that you own – that is, objects with which you
have a has-a relationship.
Once you've added delete iObject1 to CExampleAppUi's destructor, rebuild
memorymagic and start it again. Select New 1 twice, and then exit. You'll get another panic.
The reason for this should be obvious. The second time through, we simply created a
second CX, stored its address in iObject1, and forgot the address of the CX object we
allocated previously. There was no way for the destructor – or any other part of the C++
system – to find this object, so it couldn't be deleted.
We could have solved this by coding:
case EMagicCmdNew1:
delete iObject1;
iObject1 = new CX;
iEikonEnv->InfoMsg(_L("New 1"));
break;
Here, we're taking advantage of the zero-checking service that C++ provides as part of
delete. If the object has already been allocated, we delete it and allocate it again. If it
hasn't yet been allocated, the delete statement will do nothing.
If you build this new line into memorymagic, you should find that it exits cleanly no matter
how many times you select New 1.
There is one other technique that can help us to avoid allocating twice. We can ensure that
this does not happen by adding an ASSERT before allocating member variables, like this:
ASSERT(iObject1 == NULL);
iObject1 = new CX;
Don't allocate twice
If double allocation is a serious crime, then deleting twice is a capital offense. If you allocate
something twice, the result is a heap cell that doesn't get destroyed, which gets picked up
eventually by a __UHEAP_MARKEND. If you delete something twice, the effects can be more
subtle.memorymagic can demonstrate this effect too. Select New 1 from the menu, and
then select Delete 1 twice. In this case, I found that the application panics immediately, but
in other situations I haven't always been so lucky: double deletion doesn't always cause an
immediate crash, and sometimes it leaves side effects that only surface a long time after the
real problem – the double delete – occurred. As a result, double deletes are very hard to
debug.
On the other hand, double deletes are easy to avoid – just follow this little discipline:
Important
C++ delete does not set the pointer to zero. If you delete any member
object from outside its class's destructor, you must set the member
pointer to NULL.