Is there any flaw in this complex class using RPointerArray?

Login to reply to this topic.
Wed, 2008-03-26 05:42
Eric.Pen
Joined: 2008-03-18
 Forum posts: 23

class CFamily : public CBase
{
public:
   RPointerArray<CMyClass>* array1; 
   RPointerArray<CMyClass>* array2; 
   RPointerArray<HBufC>*       array4;
public:
   static CFamily* NewLC()
  {
        CFamily* self =  CFamily::NewL();
        CleanupStack::Pop();
        return self;
  };
  staic CFamily* NewL()
{
       CFamily* self = new (ELeave) CFamily;
       CleanupStack::PushL();
       self->ConstructL();
       return self;
};
public:
   void ConstructL()
   {
        array1 = new (ELeave) RPointerArray(1); //may leave
        CleanupStack::PushL(array1);
        CleanupClosePushL( *array1);

        array2 = new (ELeave) RPointerArray(1); //may leave
        CleanupStack::PushL(array2);
        // utility in MMFController
        CleanupResetAndDestroy::PushL(*array2);


        array4 =  new (ELeave) RPointerArray(1); //may leave
        CleanupStack::PushL(array4);
        CleanupResetAndDestroy:PushL(*array4);
        HBufC *element = HBufC::NewL(10);
        array4.AppendL(element);

       
   };
   ~CFamily()
   {
        CleanupStack::PopAndDestroy(array1);
        CleanupStack::PopAndDestroy(array1);

        CleanupStack::PopAndDestroy(array2);
        CleanupStack::PopAndDestroy(array2);

        CleanupStack::PopAndDestroy(array4);
        CleanupStack::PopAndDestroy(array4);
   };
}

----------------------------------------------------
I design this class for challenge the useage of RPointerArray Smiling ,and i doubt the difference between CleanupClosePushL and CleanupResetAndDestroy::PushL,who can figure it out?

Wed, 2008-03-26 10:40
eric
NewLC AdministratorSymbian AccreditedForum Nokia Champion
Joined: 2003-01-14
 Forum posts: 2006
Re: Is there any flaw in this complex class using RPointerArray?

There are at least many flaws in your code. You should really consider practicing a bit more before thinking about flaws in system implementation (btw, could you mention what flaws do you see in RPointerArray ? ):
- RPointerArray are R-classes. You do not need to allocate them with new(ELeave).
- you should NEVER put class data members on the cleanup stack

Eric Bustarret
NewLC Founder & CEO / Professional Symbian OS Consultant

 
Wed, 2008-03-26 15:05
Eric.Pen
Joined: 2008-03-18
 Forum posts: 23
Re: Is there any flaw in this complex class using RPointerArray?

Oh,My God . Sad Sad Sad Sad I 'm sorry and actually make these mistakes.

U are right ,Eric. There is no need to allocate R-class with new(ELeave) and yet the Kernel resources always need to protected .
As far as i know Kernel resources used by the R-objects like RPointerArray are need protected via CleanupClosePushL.
Then how can we avoid the resoures unclose when exception happend. The array is member of a class ,we cannot push the array to the cleanup stack??

PS:Of course there is no flaw in system implementation , i just doubt the useage of mine.

Eric.Pen

 
Wed, 2008-03-26 16:19
eric
NewLC AdministratorSymbian AccreditedForum Nokia Champion
Joined: 2003-01-14
 Forum posts: 2006
Re: Is there any flaw in this complex class using RPointerArray?

As far as i know Kernel resources used by the R-objects like RPointerArray are need protected via CleanupClosePushL.

You are right. However in your case this is the CFamily object that you need to put on cleanup stack (unless it is itself a data member of another class). Deleting the object (either by calling delete or PopAndDestroy) will call its destructor and this is where you just need to call RPointerArray::Reset or RPointerArray::ResetAndDestroy to clean the array.

Eric Bustarret
NewLC Founder & CEO / Professional Symbian OS Consultant

 
Wed, 2008-03-26 17:24
Numpty Alert
Joined: 2007-09-23
 Forum posts: 159
Re: Is there any flaw in this complex class using RPointerArray?


And find out what array granularity is for.

 
Thu, 2008-03-27 02:39
Eric.Pen
Joined: 2008-03-18
 Forum posts: 23
Re: Is there any flaw in this complex class using RPointerArray?

Ok, thing seems to be clear , AND i really understand where is my fault ! I should not put the member data of class to the cleanup stack , because the class itself is in charge of member's destruction. What am i doing in this wrong case is: put the member data to the cleanupstack and then new a C-object of CFamily , finally push this object to the stack , Shocked Shocked Shocked Shocked Shocked
All action is just in disorder.

By the way , when the element insertion causes the array to re-allocated , the granularity is the length to increase .

Whatever ,thanks for the eric's help ! Thanks !

 
Thu, 2008-03-27 17:52
Andreas
Joined: 2003-12-05
 Forum posts: 672
Re: Is there any flaw in this complex class using RPointerArray?

Also, NewL and NewLC are the wrong way around -- NewLC should leave object on the cleanup stack, NewL should not.

Edit: Please learn to use the naming conventions too. Knowing, by the name of the variable, if it is a member variable or not, is a very valuable help. As you have now learned from the R class usage too.

 
Thu, 2008-03-27 21:12
Numpty Alert
Joined: 2007-09-23
 Forum posts: 159
Re: Is there any flaw in this complex class using RPointerArray?

Yes that is what the granularity is for.

So therefore it is a bad idea to have a granulatory of 1 if your array is going to store more than a handful of items. i.e. if the array will store 500 items, then every time an item is added a new heap cell will have to be found and allocated, and potentially the entire contents of the existing array copied to its new location.
But that does not imply a granulatory if 500 should necessarily be chosen. You need to choose the figure with care given the anticipated likley number of elements.

Using a granularity of 1 with CBufFlat/CBufSeg is much worse a crime that should result in imprisonment for 6 months for the offender.

 
Fri, 2008-03-28 11:20
Eric.Pen
Joined: 2008-03-18
 Forum posts: 23
Re: Is there any flaw in this complex class using RPointerArray?

Wohoo , I am so reckless of making a clerical error about the usage of "NewL and NewLC" , as Numpty Alert says ,this
low-grade fault should result in imprisonment for 6 months for the offender , Evil Evil Evil Thank you Andreas !

Just Now i turn over the SDK and learn more about the granularity . Actually we need to think about this parameter twice before we use .

The granularity should be carefully chosen. Too small a value will result in too many re-allocations with a cost in time and, due to fragmentation and segmentation overheads, some waste of space also. Too large a value will result in over-allocation of space: the extent of the waste of space depends on the type of data in the buffer: decisions must be made on a case-by-case basis.

Frequently swtich between the User-State and Core-State when re-allocation needs costs the time !!
Thanks Numpty Alert ,Thanks All

 
Mon, 2008-03-31 15:30
alh
Joined: 2004-11-29
 Forum posts: 1233
Re: Is there any flaw in this complex class using RPointerArray?


Frequently swtich between the User-State and Core-State when re-allocation needs costs the time !!

Nope.
I'm pretty sure what takes time is walking the heap to find a new cell, and copy the old data to the new cell, not any context switching to kernel space (if it is at all needed)

btw, didn't see anyone else answer that particular question; Isn't the difference between CleanupResetAndDestroyPushL and CleanupClosePushL quite obvious?
One will call "Close", and the other will call "ResetAndDestroy" on the array.
The difference is documented in the SDK documentation; Close will just deallocate the array, while ResetAndDestroy() also will call "delete" on any pointer stored in the array, so the destructor of the object(s) is called.

One is to be used if your array takes ownership of the object you store pointers too, and the other when it isn't.

Afaik there is no difference between "Close" and "Reset" though.

 
Mon, 2008-03-31 18:55
Andreas
Joined: 2003-12-05
 Forum posts: 672
Re: Is there any flaw in this complex class using RPointerArray?

Afaik there is no difference between "Close" and "Reset" though.

After calling Close, array space is freed, and you should not use the array anymore since it is "closed" and resources related to using it are freed. After calling Reset, the array space is freed but you still can use the array. That's the basic idea. Have never tried, however, if it hurts to Close the array and still trying to use it...

 
Tue, 2008-04-01 02:58
Eric.Pen
Joined: 2008-03-18
 Forum posts: 23
Re: Is there any flaw in this complex class using RPointerArray?

void Close();
Description
Closes the array and frees all memory allocated to the array.
The function must be called before this array object is destroyed.

void Reset();
Description
Empties the array, so that it is ready to be reused.
The function frees all memory allocated to the array and resets the internal state so that it is ready to be reused.
This array object can be allowed to go out of scope after a call to this function.

There is one clear point : both of them ensure that allocated memory is freed, there is no memory leak at all after that .

 
Tue, 2008-04-01 07:41
Andreas
Joined: 2003-12-05
 Forum posts: 672
Re: Is there any flaw in this complex class using RPointerArray?

There is one clear point : both of them ensure that allocated memory is freed, there is no memory leak at all after that .

As long as you remember that Reset and Close (as told above) release the memory allocated to the array (the memory allocated to hold the pointers), but it does not release the memory of the objects pointed to by the pointers in the array. For that, you need to call ResetAndDestroy (as told already). Just wanted to make sure this is understood.

 
Tue, 2008-04-01 08:13
Eric.Pen
Joined: 2008-03-18
 Forum posts: 23
Re: Is there any flaw in this complex class using RPointerArray?

Of course, Andreas !
After online discussion and carefully refining , i have well learned how to use the class " RArray/PointerArray" correctly .
Smiling Smiling Smiling

 
  • Login to reply to this topic.