Symbian3/SDK/Source/GUID-7A71CD0B-84C7-5A77-B573-C61F67C382DA.dita
changeset 0 89d6a7a84779
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Symbian3/SDK/Source/GUID-7A71CD0B-84C7-5A77-B573-C61F67C382DA.dita	Thu Jan 21 18:18:20 2010 +0000
@@ -0,0 +1,39 @@
+<?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-7A71CD0B-84C7-5A77-B573-C61F67C382DA" xml:lang="en"><title>Summary
+of cleanup rules</title><shortdesc>This document states general rules for cleanup.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>The general rules for cleanup during the lifetime of an object are:</p>
+<ul>
+<li id="GUID-AEE55F10-3FD5-5B09-B025-C5499DE7B312"><p>between the moment the
+object is allocated, and the moment that a pointer to that object is stored
+in a structure which would be accessible if a leave occurred, the object must
+be pushed to the clean-up stack if a leave could possibly occur</p> </li>
+<li id="GUID-B69DDE00-FE4C-582F-B5FA-0FA7684591F6"><p>when a pointer to the
+object has been stored in an object which would be accessible if a leave occurred,
+then the object should be popped from the cleanup stack before a leave could
+possibly occur: normally, the object is popped first, and then the pointer
+is stored</p> </li>
+<li id="GUID-D8D6B31E-0B9F-56C6-B9B0-2197549E78FC"><p>an object is accessible
+if a leave occurs, if either it is pushed to the cleanup stack, or there is
+a reference to it from another object which would be accessible if a leave
+occurred, or there is a reference to it from a stack frame which would not
+be affected when a leave occurs (because of an appropriately-placed <codeph>TRAP</codeph>),
+or there is a reference to it from a global variable</p> </li>
+<li id="GUID-4F508BDB-59D1-52EA-84C2-CABE3E9339EC"><p>it should never be possible
+to clean up an object more than once, if a leave occurred</p> </li>
+</ul>
+<p>In practice, this means that an object must be referred to either by a
+cleanup stack frame, or by a reference from another object. More rarely, the
+object may be referred to by a stack frame which cannot be unwound during
+the lifetime of that object, because of an appropriate <codeph>TRAP</codeph>.
+More rarely still, the object may be referred to by a global variable.</p>
+</conbody></concept>
\ No newline at end of file