Symbian有待理解的部分

As we’ve seen, deleting an object is simply a matter of using the delete
operator on a pointer to the object to be deleted. If a pointer is already
zero, then calling delete on it is harmless. However, you must be
aware that delete does not set the pointer itself to zero. While this
does not matter if you are deleting an object from within a destructor, it
is very important if the deletion occurs anywhere else. 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:
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.


To make this easier, and transparent, we use the NewL() and NewLC()
patterns. The CZ class has a static NewLC() function that’s coded:
CZ* CZ::NewLC()
{
CZ* self = new(ELeave) CZ;
CleanupStack::PushL(self);
self->ConstructL();
return self;
}
Because CZ::NewLC() is static, you can call it without any existing
instance of CZ. The function allocates a CZ with new(ELeave) and then
pushes it on to the cleanup stack so that the second-phase constructor can
then safely be called. If the second-phase constructor fails then the object
is popped and destroyed by the rules of the cleanup stack. If all goes well,
it leaves it on the cleanup stack – that’s what the C in NewLC() stands
for. NewLC() is useful if, on returning, we want to refer to the new CZ
from an automatic variable.
Often, however, we don’t want to keep the new CZ on the cleanup
stack, and we use the NewL() static function that can be coded:
CZ* CZ::NewL()
{
CZ* self = new(ELeave) CZ;
CleanupStack::PushL(self);
self->ConstructL();
CleanupStack::Pop();
return self;
}
This is exactly the same as NewLC() except that we pop the CZ object
off the cleanup stack after the second-phase constructor has completed
successfully, that is, after the second-phase constructor has returned.
18 SYMBIAN OS FUNDAMENTALS
As you can see, the two implementations are almost the same, and you
will commonly see NewL() implemented in terms of NewLC() like this:
CZ* CZ::NewL()
{
CZ* self = CZ::NewLC();
CleanupStack::Pop();
return self;
}
One interesting thing to note in the NewL() implementation is that we
have popped an item from the cleanup stack without destroying it. All
we’re doing here is putting a pointer on to the cleanup stack only for as
long as there is a risk of leaving. The implication is that on return from the
NewL(), ownership of the object is passed back to the caller of NewL()
who then has to take responsibility for it.
CZ::NewLC() and CZ::NewL() operate as factory functions –
static functions that act as a kind of constructor.


The area occupied by data represented by a descriptor is considered to
be non-expandable, even though the length of data actually represented
can shrink, or expand to fill that area. The area is created, or defined,
when the descriptor is created.

? Insert() inserts data into any position, pushing subsequent data
towards the end of the descriptor data area.
? Delete() deletes any sequence of data, moving down subsequent
data to close the gap.
? Replace() overwrites data in the middle of the descriptor data area.

The active scheduler is, in effect, a ‘wait loop’ which waits for events
and, on receipt of a signal marking the occurrence of an event, decides
which event has occurred of the many it may be expecting, and then
dispatches the RunL() function of the appropriate active object.
In fact, the UI framework maintains an outstanding request to the
window server for user input and other system events. When this request
completes, it calls the appropriate application UI and control functions to
ensure that your application handles the event properly. So, ultimately,
all application code is handled under the control of an active-object
RunL().