Symbian3/SDK/Source/GUID-FE138F1A-1F52-5E9A-8EB2-5A8945A9CF30.dita
changeset 0 89d6a7a84779
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Symbian3/SDK/Source/GUID-FE138F1A-1F52-5E9A-8EB2-5A8945A9CF30.dita	Thu Jan 21 18:18:20 2010 +0000
@@ -0,0 +1,36 @@
+<?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>
\ No newline at end of file