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