Symbian3/PDK/Source/GUID-011D0974-CC37-5335-A8EB-7ECF4FC30F93.dita
changeset 14 578be2adaf3e
parent 5 f345bda72bc4
--- a/Symbian3/PDK/Source/GUID-011D0974-CC37-5335-A8EB-7ECF4FC30F93.dita	Tue Jul 20 12:00:49 2010 +0100
+++ b/Symbian3/PDK/Source/GUID-011D0974-CC37-5335-A8EB-7ECF4FC30F93.dita	Fri Aug 13 16:47:46 2010 +0100
@@ -1,41 +1,41 @@
-<?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-011D0974-CC37-5335-A8EB-7ECF4FC30F93" xml:lang="en"><title>Cleanup
-for heap arrays</title><shortdesc>C++ arrays are allocated on the heap and require their own particular
-cleanup.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
-<p>C++ arrays are allocated on the heap using <codeph>operator new[]</codeph>.
-The cleanup rules for such arrays are as follows:</p>
-<ul>
-<li id="GUID-41AA28AA-1D48-5B50-9065-A283CCAAD83F"><p>if it is not necessary
-to protect against leaves, such as when the array is a class member, or no
-leaves can occur in the lifetime of the array, then always delete the array
-using <codeph>operator delete[]</codeph> (not <codeph>operator delete</codeph>).</p> </li>
-<li id="GUID-B4EA79E7-EEDC-531D-90DB-7041F3650356"><p>if it is necessary to
-protect against leaves, push the array to the cleanup stack using the utility
-template function <codeph>CleanupArrayDeletePushL()</codeph>. This ensures
-that if a leave occurs, the array is deleted correctly using <codeph>operator
-delete[]</codeph>.</p> <p>Arrays should <i>not</i> be pushed to the cleanup
-stack using the standard <codeph>CleanupStack::PushL()</codeph>, as this will
-result in <codeph>operator delete</codeph> rather than <codeph>operator delete[]</codeph> being
-used for cleanup.</p> </li>
-</ul>
-<p><b>Note on compiler behaviour</b> </p>
-<p>Of the compilers used with Symbian platform, Metrowerks CodeWarrior is
-the most sensitive to the rules for array deletion. If an array is deleted
-with a simple <codeph>delete</codeph> rather than <codeph>delete[]</codeph>,
-then a USER 42 panic (invalid heap cell) can occur. </p>
-<p>This panic in fact occurs for arrays in which the class has either a constructor
-or a destructor. For such arrays, CodeWarrior reserves space at the start
-of the array storage to hold the number of elements in the array: this means
-the first heap cell is not the start of a deletable object. GCC and MSVC C++
-only reserve such extra space if the class has a destructor.</p>
+<?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-011D0974-CC37-5335-A8EB-7ECF4FC30F93" xml:lang="en"><title>Cleanup
+for heap arrays</title><shortdesc>C++ arrays are allocated on the heap and require their own particular
+cleanup.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>C++ arrays are allocated on the heap using <codeph>operator new[]</codeph>.
+The cleanup rules for such arrays are as follows:</p>
+<ul>
+<li id="GUID-41AA28AA-1D48-5B50-9065-A283CCAAD83F"><p>if it is not necessary
+to protect against leaves, such as when the array is a class member, or no
+leaves can occur in the lifetime of the array, then always delete the array
+using <codeph>operator delete[]</codeph> (not <codeph>operator delete</codeph>).</p> </li>
+<li id="GUID-B4EA79E7-EEDC-531D-90DB-7041F3650356"><p>if it is necessary to
+protect against leaves, push the array to the cleanup stack using the utility
+template function <codeph>CleanupArrayDeletePushL()</codeph>. This ensures
+that if a leave occurs, the array is deleted correctly using <codeph>operator
+delete[]</codeph>.</p> <p>Arrays should <i>not</i> be pushed to the cleanup
+stack using the standard <codeph>CleanupStack::PushL()</codeph>, as this will
+result in <codeph>operator delete</codeph> rather than <codeph>operator delete[]</codeph> being
+used for cleanup.</p> </li>
+</ul>
+<p><b>Note on compiler behaviour</b> </p>
+<p>Of the compilers used with Symbian platform, Metrowerks CodeWarrior is
+the most sensitive to the rules for array deletion. If an array is deleted
+with a simple <codeph>delete</codeph> rather than <codeph>delete[]</codeph>,
+then a USER 42 panic (invalid heap cell) can occur. </p>
+<p>This panic in fact occurs for arrays in which the class has either a constructor
+or a destructor. For such arrays, CodeWarrior reserves space at the start
+of the array storage to hold the number of elements in the array: this means
+the first heap cell is not the start of a deletable object. GCC and MSVC C++
+only reserve such extra space if the class has a destructor.</p>
 </conbody></concept>
\ No newline at end of file