NewLC - RPointerArray and CleanupStack - Comments

Re: RPointerArray and CleanupStack

Andreas — Tue, 15 Apr 2008 21:35:55 +0200

OK, just to return to the issue of allocating R objects in the heap, just check out this new article on Symbian DevNet: http://developer.symbian.com/main/downloads/papers/advanced_RArray.pdf

It has a chapter on this issue...

Re: RPointerArray and CleanupStack

alh — Mon, 14 Apr 2008 09:53:12 +0200

Could you please point me to the place in the documentation where it says that R-objects should be allocated on the stack?
I can't find it.
In the "class types" section, they don't say a word of where you should keep them.

I agree that it apparently is not obvious that member variables of objects allocated on the heap is also on the heap.

But don't you think its gets even more confusing for the "newbies" when a lot of "experts" reiterate that "R-Objects should be on the stack" and then almost every example and real usage has them as member variables of CBase objects? And indeed this way usually produces the most simple and easy-to-maintain code?
Don't really promote understanding

Re: RPointerArray and CleanupStack

Andreas — Sat, 12 Apr 2008 18:11:15 +0200

Could you please point me to the place in the documentation where it says that R-objects should be allocated on the stack?
I can't find it.

I believe we all agree on this issue already.

The point is that you shouldn't dynamically allocate R objects using new (ELeave).

That I guess we also agree. No point in continuing, since no one else participates this discussion anymore

Re: RPointerArray and CleanupStack

Numpty Alert — Thu, 10 Apr 2008 22:12:52 +0200

When people say RObjects should live on the stack, and indeed when the documentation says that, it is actually incorrect from a literal point of view in the interpretation of English, but think of it as a phrase, and what it actually means is they are not intended to be directly allocated on the heap. The SDK says this and they should be chastised for doing so and it should be re-written to be accurate, as I should be castised for saying not on the stack in my original posting when I meant not directly allocated on the heap which is what I meant 6to say.

R objects can go:
a) be allocated on the heap directly
b) be allocated on the heap indirectly because they are members of a C class
c) be on the stack.

They are intended for use as b or c.

a) is possible and there is nothing to stop you from doing so, and you will even find examples in the Symbian source code where they are (just becasue you see something in Symbian doesn't mean it is correct, there are lots of examples of bad programing in Symbian code).
Howeverif you allocate an R object on the heap directly then frequently making it leave safe can become more complex. So while it is possible to allocate them directly on the heap, if this makes things more complex than not directly allocating them on the heap, then what is the point in choosing complexity when you can choose simplicity?

Alh, I didn't do a good job of saying why newbies could be more confused now - because newbies quite often don't know if a nested object inside a C object is on the stack or the heap. Its obvious to us that it is, but from seeing many people's postings in the past its obvious its not obvious to newbies or numpties.

As should be obvious from what I have previously said, and what Alh has stated explicitly - the bad code of the original function is causing bad ripples throughout the rest of the code.
if it better to fix that function rather than work around it.

Re: RPointerArray and CleanupStack

Andreas — Thu, 10 Apr 2008 14:17:18 +0200

Or do as I fixed, pop it out in the FillArrayL as I originally intented. Fixed it to the code. Optionally do as alh said.

Re: RPointerArray and CleanupStack

Andreas — Thu, 10 Apr 2008 14:15:55 +0200

OK, OK I confess being too vague about the R -classes. You do not need to "allocate them on the stack" but as already said, you usually shouldn't dynamically allocate them (though you can; see e.g. Babin: Developing Software for Symbian OS, 2nd Ed, p. 76).

What your example here does is that it actually fills a RPointerArray with objects for the caller. Why not avoid the dynamic allocation of R object like this:

void CUtils::FillArrayL(TInt aCount, RPointerArray<CMyClass> & aArray)
{
      aArray.ResetAndDestroy(); // Optional if the array should be emptied first. Caller could do this too.
      CleanupResetAndDestroyPushL(aArray);
      for(TInt ct = 0; ct < Count; ct++)
     {
          CMyClass *myClass = CMyClass::NewL(ct);
          CleanupStack::PushL(myClass);
          aArray.AppendL(myClass);
          CleanupStack::Pop();
     }
     CleanupStack::Pop(); // Thanks, alh, for pointing out this one.
}

Now you do not have to do dynamic allocation in order to return a local object from the method. Let the caller take care of the construction of the array object.

void  CUtils::UseArrayL()
{
     RPointerArray<CMyClass> myArray;
     FillArrayL(10, myArray);

     /* do something, and if it can leave, push myArray to cleanup stack again! */
     mArray.ResetAndDestroy();
}

See, no need to dynamically allocate RPointerArray, much simpler code to use.

Re: RPointerArray and CleanupStack

alh — Thu, 10 Apr 2008 13:15:07 +0200

Just one note, the FillArrayL in andreas post should be named FillArrayLC (since it leaves a cleanupitem on the cleanupstack)

And you would have to do either:

CleanupStack::Pop()
mArray.ResetAndDestroy();

or simply:

CleanupStack::PopAndDestroy()

to empty it in the end of UseArrayL

Re: RPointerArray and CleanupStack

alh — Thu, 10 Apr 2008 09:41:56 +0200

Alh you're right you've confused them even more.

Well, imho, what is confusing is everyone reiterating this falsehood about "R-classes are supposed to live on the stack".
Its just not true at all, and just very confusing for people trying to understand how it really works.

What is true though is that they are _not_ supposed to be owned via a pointer, and you should _not_ use new to create them.

But that does _not_ mean "they should be on the stack"....
Contrary to CBase objects they _can_ be put on the stack, but that is very far from "they have to be on the stack".

But... just to be extra clear:
You should go to your architect or whoever decided that function signature and tell him it is a bad design, and why, and convince him to change it.
It has a faulty design, and will create a lot of extra work for you (which you have already started to notice) and probably be a source of a few defects...

Re: RPointerArray and CleanupStack

rbrunner — Thu, 10 Apr 2008 06:41:13 +0200

I qoute from Andreas' post:

As R classes are designed not to be dynamically allocated, why do it when you can live without it?!

You can continue to hit your head with a hammer, but why should you?

Re: RPointerArray and CleanupStack

prajwal.r.m — Thu, 10 Apr 2008 06:39:54 +0200

Hi,

To make every one clear it is not at all a strict convention to allocate a R based object on stack, even the R object itself uses heap internally when u call Append or insert in case of
RPointerArray so no confusion about stack or heap both work .

Now
mac123

As you can see the method
CleanupResetAndDestroyPushL( pMyArray); is in #include "mmfcontrollerpluginresolver.h" which is a specific to MMF

so it is as good as saying that MMF has written its own cleanp operation CleanupResetAndDestroyPushL( pMyArray);

So I think internally he is also using the same TCleanupItem solution which i gave you.

It is always better to ve your own cleanup operation.

So just use the second one to better understanding and correct cleanup .

Re: RPointerArray and CleanupStack

mac123 — Thu, 10 Apr 2008 03:58:28 +0200

hello guys,

I am totally lost now..

From the discussion we had here, I understood that there is nothing wrong in allocating RPOinterArray on stack or heap.. Only thing is that we should be cautious to call ResetAndDestroy, Close on RPointerArray.. Also we need to delete the RPointerArray Pointer.. Is that my understanding correct ??

And there are basically 2 ways to implement the cleanupStack. 1/ CleanupResetAndDestroyPushL and 2/ TCleanUpItem. which one is the preferred solution ?

Just to summarize, I will put both the solution here..

1/CleanupResetAndDestroyPushL

#include "mmfcontrollerpluginresolver.h"

RPointerArray<CMyClass>*  CUtils::CreateRpointerL(TInt Count)
{
       RPointerArray<CMyClass> *pMyArray = new (ELeave)RPointerArray<CMyClass>();
      CleanupResetAndDestroyPushL( pMyArray);
       for(TInt ct = 0; ct < Count; ct++)
     {
          CMyClass *myClass = CMyClass::NewL(ct);
          CleanupStack::PushL(myClass);
          (*pMyArray).AppendL(myClass);
          CleanupStack::Pop();
     }
      
     CleanupStack::Pop();
     return pMyArray;
}

2/ Using TCleanupItem

void CleanupResetAndDestroy(TAny*  aItem)
{
RPointerArray<CMyClass> *pMyArray = (RPointerArray<CMyClass>*) aItem;
pMyArray->ResetAndDestroy();
pMyArray->Close();
delete  pMyArray;
}
RPointerArray<CMyClass>*  CUtils::CreateRpointerL(TInt Count)
{
     RPointerArray<CMyClass> *pMyArray = new (ELeave)RPointerArray<CMyClass>();
     CleanupStack::PushL(TCleanupItem(CleanupResetAndDestroy(pMyArray ));
     for(TInt ct = 0; ct < Count; ct++)
     {
          CMyClass *myClass = CMyClass::NewL(ct);
           CleanupStack::PushL(myClass);
          (*pMyArray).AppendL(myClass);
          CleanupStack::Pop();
     }
     return pMyArray;
   CleanupStack::Pop();
}

Thanks
Mac

Re: RPointerArray and CleanupStack

Numpty Alert — Wed, 09 Apr 2008 19:40:29 +0200

Alh you're right you've confused them even more.

That unchangeable function signature is incorrect by the way, there is no trailing L in its name to indicate it is a leaving function. And there is a memory leak if AppendL() leaves. So if that function can't be changed then whats the point of making the calling code leave safe if the function its calling isn't itself leave safe?

Re: RPointerArray and CleanupStack

alh — Wed, 09 Apr 2008 17:05:30 +0200

I can't remember having my RPointerArrays on the stack, ever.

I keep them as a member variable of a CBase object, thus... on the heap.

Though, you are right you shouldn't use new explicitly to create it....

Just wanted to confuse everyone some more

Re: RPointerArray and CleanupStack

Andreas — Wed, 09 Apr 2008 08:12:42 +0200

You are absolutely right, there is no such restriction on RPointerArray that it has to be allocated on to the stack.

But it will make things more complex. As R classes are designed not to be dynamically allocated, why do it when you can live without it?!

Often novices make the mistake of allocating R objects from heap and then just deleting it. This will cause problems since they do not remember to call Close (Reset/ResetAndDestroy/whatever) needed to really release the resources allocated by the R object. delete does not do this and R destructors usually do not do this. You need to call Close explicitly.

So just make your life easier, do not allocate R on heap but on stack, call Close (whatever) in the end and that's it. Furthermore, if your R object is actually a member variable of a C class, the memory used by the R object is actually on the heap already. So this does not save stack memory. The only place where stack is saved is when you use the R object inside a method temporarily. Finally, R classes do not often spend a lot of memory anyways, since the actual work with the actual data is done somewhere else, in a server usually.

Re: RPointerArray and CleanupStack

prajwal.r.m — Wed, 09 Apr 2008 06:46:27 +0200

Hi,

You are absolutely right, there is no such restriction on RPointerArray that it has to be allocated on to the stack.
Now for cleanup purpose, CleanupStack provides 3 variants of PushL(). One of the variant takes TCleanupItem. For instance in your case the RPointerArray cannot simply be deleted(since we need to call Reset on it and delete all the pointers it contains), so you ve use this overloaded version of PushL (TCleanupItem aItem).This method allows us to define our own cleanup operation.The following code ll make you clear

void CleanupResetAndDestroy(TAny*  aItem)
{
RPointerArray<CMyClass> *pMyArray = (RPointerArray<CMyClass>*) aItem;
pMyArray.ResetAndDestroy();
pMyArray.Close();
delete  pMyArray;
//or u can use free if u dont ve any destructor
}
RPointerArray<CMyClass>*  CUtils::CreateRpointer(TInt Count)
{
     RPointerArray<CMyClass> *pMyArray = new (ELeave)RPointerArray<CMyClass>();
     CleanupStack::PushL(TCleanupItem(CleanupResetAndDestroy(pMyArray ));
     for(TInt ct = 0; ct < Count; ct++)
     {
          CMyClass *myClass = CMyClass::NewL(ct);
          (*pMyArray).AppendL(myClass);
     }
     return pMyArray;
   CleanupStack::Pop();
}

The CleanupResetAndDestroy operation is called when the subsequent call to CleanupStack::PopAndDestroy is made
Now Suppose the NewL of CMyClass leaves, CleanupResetAndDestroy is called and the cleanup is done.
This operation is more useful where u ve opened several resources and u need to cleanup.
I hope this is clear

RPointerArray and CleanupStack

mac123 — Tue, 08 Apr 2008 15:44:34 +0200

Hello All,

I am trying to understand how the RPointerArray works

I have written a piece of code as below and it is working perfectly fine.



RPointerArray*  CUtils::CreateRpointer(TInt Count)

{

     RPointerArray *pMyArray = new (ELeave)RPointerArray();

     for(TInt ct = 0; ct < Count; ct++)

     {

read more