Symbian3/SDK/Source/GUID-FE138F1A-1F52-5E9A-8EB2-5A8945A9CF30.dita
author Graeme Price <GRAEME.PRICE@NOKIA.COM>
Fri, 15 Oct 2010 14:32:18 +0100
changeset 15 307f4279f433
parent 0 89d6a7a84779
permissions -rw-r--r--
Initial contribution of the Adaptation Documentation.

<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-FE138F1A-1F52-5E9A-8EB2-5A8945A9CF30" xml:lang="en"><title>Destructor
requirements</title><shortdesc>This document describes cleanup actions required for C type and
other classes.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>For <codeph>C</codeph> type classes, cleanup invokes the destructor. For
other types of object, other actions may be required. </p>
<p>The destructor for <codeph>C</codeph> type classes must be coded to release
all resources owned by the object. By definition, cleanup may occur on <i>partially</i> constructed
objects: the destructor may not, therefore, assume that all conditions for
a fully-constructed object hold in these circumstances. A typical situation
to watch for is calling a member function on a pointer that is initialized
in the <codeph>ConstructL()</codeph>, as the pointer could be <codeph>NULL</codeph> in
failure cases.</p>
<p>Resources will usually be indicated by pointers or handles. It is important
that such pointers or handles are null when there is no resource allocated,
and that the destructor test for a non-null value before destroying them.</p>
<p>This behaviour is facilitated in <codeph>CBase</codeph> -derived classes,
because their memory is guaranteed to be initially set to binary zeroes when
they are first allocated.</p>
<p>Programmers must, however, take particular care with pointers which are
used for owned objects which are repeatedly allocated and de-allocated throughout
an object’s lifetime. When such owned objects are de-allocated, the pointer
should always immediately be set to null.</p>
<section id="GUID-DFAB4D8D-FD81-4754-9472-2BCFD8B90F9E"><title>See also</title> <p><xref href="GUID-7366AE99-DE25-5DE0-BF9A-58E7742DA952.dita">Advanced
Cleanup</xref>.</p> </section>
</conbody></concept>