1 <?xml version="1.0" encoding="utf-8"?>

     2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

     3 <!-- This component and the accompanying materials are made available under the terms of the License 

     4 "Eclipse Public License v1.0" which accompanies this distribution, 

     5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

     6 <!-- Initial Contributors:

     7     Nokia Corporation - initial contribution.

     8 Contributors: 

     9 -->

    10 <!DOCTYPE concept

    11   PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

    12 <concept id="GUID-FE138F1A-1F52-5E9A-8EB2-5A8945A9CF30" xml:lang="en"><title>Destructor

    13 requirements</title><shortdesc>This document describes cleanup actions required for C type and

    14 other classes.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

    15 <p>For <codeph>C</codeph> type classes, cleanup invokes the destructor. For

    16 other types of object, other actions may be required. </p>

    17 <p>The destructor for <codeph>C</codeph> type classes must be coded to release

    18 all resources owned by the object. By definition, cleanup may occur on <i>partially</i> constructed

    19 objects: the destructor may not, therefore, assume that all conditions for

    20 a fully-constructed object hold in these circumstances. A typical situation

    21 to watch for is calling a member function on a pointer that is initialized

    22 in the <codeph>ConstructL()</codeph>, as the pointer could be <codeph>NULL</codeph> in

    23 failure cases.</p>

    24 <p>Resources will usually be indicated by pointers or handles. It is important

    25 that such pointers or handles are null when there is no resource allocated,

    26 and that the destructor test for a non-null value before destroying them.</p>

    27 <p>This behaviour is facilitated in <codeph>CBase</codeph> -derived classes,

    28 because their memory is guaranteed to be initially set to binary zeroes when

    29 they are first allocated.</p>

    30 <p>Programmers must, however, take particular care with pointers which are

    31 used for owned objects which are repeatedly allocated and de-allocated throughout

    32 an object’s lifetime. When such owned objects are de-allocated, the pointer

    33 should always immediately be set to null.</p>

    34 <section id="GUID-DFAB4D8D-FD81-4754-9472-2BCFD8B90F9E"><title>See also</title> <p><xref href="GUID-7366AE99-DE25-5DE0-BF9A-58E7742DA952.dita">Advanced

    35 Cleanup</xref>.</p> </section>

    36 </conbody></concept>