Cleanup +for heap arrays

diff -r 89d6a7a84779 -r 25a17d01db0c Symbian3/PDK/Source/GUID-011D0974-CC37-5335-A8EB-7ECF4FC30F93.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/PDK/Source/GUID-011D0974-CC37-5335-A8EB-7ECF4FC30F93.dita Fri Jan 22 18:26:19 2010 +0000 @@ -0,0 +1,41 @@ + + + + + +Cleanup +for heap arraysC++ arrays are allocated on the heap and require their own particular +cleanup. +

C++ arrays are allocated on the heap using operator new[]. +The cleanup rules for such arrays are as follows:

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 operator delete[] (not operator delete).
if it is necessary to +protect against leaves, push the array to the cleanup stack using the utility +template function CleanupArrayDeletePushL(). This ensures +that if a leave occurs, the array is deleted correctly using operator +delete[].

Arrays should not be pushed to the cleanup +stack using the standard CleanupStack::PushL(), as this will +result in operator delete rather than operator delete[] being +used for cleanup.

Note on compiler behaviour

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 delete rather than delete[], +then a USER 42 panic (invalid heap cell) can occur.

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.

+ \ No newline at end of file