Symbian3/SDK/Source/GUID-7A71CD0B-84C7-5A77-B573-C61F67C382DA.dita
changeset 0 89d6a7a84779
equal deleted inserted replaced
-1:000000000000 0:89d6a7a84779
       
     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-7A71CD0B-84C7-5A77-B573-C61F67C382DA" xml:lang="en"><title>Summary
       
    13 of cleanup rules</title><shortdesc>This document states general rules for cleanup.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
       
    14 <p>The general rules for cleanup during the lifetime of an object are:</p>
       
    15 <ul>
       
    16 <li id="GUID-AEE55F10-3FD5-5B09-B025-C5499DE7B312"><p>between the moment the
       
    17 object is allocated, and the moment that a pointer to that object is stored
       
    18 in a structure which would be accessible if a leave occurred, the object must
       
    19 be pushed to the clean-up stack if a leave could possibly occur</p> </li>
       
    20 <li id="GUID-B69DDE00-FE4C-582F-B5FA-0FA7684591F6"><p>when a pointer to the
       
    21 object has been stored in an object which would be accessible if a leave occurred,
       
    22 then the object should be popped from the cleanup stack before a leave could
       
    23 possibly occur: normally, the object is popped first, and then the pointer
       
    24 is stored</p> </li>
       
    25 <li id="GUID-D8D6B31E-0B9F-56C6-B9B0-2197549E78FC"><p>an object is accessible
       
    26 if a leave occurs, if either it is pushed to the cleanup stack, or there is
       
    27 a reference to it from another object which would be accessible if a leave
       
    28 occurred, or there is a reference to it from a stack frame which would not
       
    29 be affected when a leave occurs (because of an appropriately-placed <codeph>TRAP</codeph>),
       
    30 or there is a reference to it from a global variable</p> </li>
       
    31 <li id="GUID-4F508BDB-59D1-52EA-84C2-CABE3E9339EC"><p>it should never be possible
       
    32 to clean up an object more than once, if a leave occurred</p> </li>
       
    33 </ul>
       
    34 <p>In practice, this means that an object must be referred to either by a
       
    35 cleanup stack frame, or by a reference from another object. More rarely, the
       
    36 object may be referred to by a stack frame which cannot be unwound during
       
    37 the lifetime of that object, because of an appropriate <codeph>TRAP</codeph>.
       
    38 More rarely still, the object may be referred to by a global variable.</p>
       
    39 </conbody></concept>