Symbian3/PDK/Source/GUID-FE138F1A-1F52-5E9A-8EB2-5A8945A9CF30.dita
author Dominic Pinkman <Dominic.Pinkman@Nokia.com>
Thu, 11 Mar 2010 18:02:22 +0000
changeset 3 46218c8b8afa
parent 1 25a17d01db0c
child 5 f345bda72bc4
permissions -rw-r--r--
week 10 bug fix submission (SF PDK version): Bug 1892, Bug 1897, Bug 1319. Also 3 or 4 documents were found to contain code blocks with SFL, which has been fixed. Partial fix for broken links, links to Forum Nokia, and the 'Symbian platform' terminology issues.

<?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>