NewLC - TPtrC and destructor - Comments

Re: TPtrC and destructor

alh — Thu, 30 Nov 2006 13:00:58 +0100

Yes, just return the HBufC* so you transfer ownership,
and then call ->Des() on it whenever you "need" it as a TPtr, or do the TPtrC(buf->Ptr(),buf->Length()) thing whenever you need it as a TPtrC, but DO NOT do that in the function allocation the HBufC like you do now.

As other says, it might work, but it is not the right way to do it, and will create the problems you outline in your first post.

Re: TPtrC and destructor

NumptyAlert — Wed, 29 Nov 2006 20:47:17 +0100

Yes but when ownership is transferred i.e. a CBase derived class's NewLC() or in this example if the HBufC* is pushed to the cleanup stack and its returend and ownership is transferred.

You listed transferring ownership of the HBufC as your 2nd option, implying it wasn't being transferred in the first option. Maybe that's not what you meant so I wanted to clarify in case any readers thought you were saying ownership wasn't transferred in the fist option, only in the 2nd.

Re: TPtrC and destructor

Andreas — Wed, 29 Nov 2006 20:02:14 +0100

Quote from: NumptyAlert

Unless I've misunderstoof your posting you can't have one function push something to the cleanupstack and then expect the caller to call PopAndDestroyjust because the function it calls has a C in its name. What if FunctionLC() pushed 2 things, or 3 things or 100 things? How does the calling function know what to do?

But isn't the XxxLC naming convention just for this? Function Leaves and places something on the Cleanup stack for the caller to take away -- LC.

And implicitly (at least I haven't seen any explicit discussion on this) this (LC) always means that there is one and only one thing on the cleanupstack you are supposed to pop (and usually destroy).

Re: TPtrC and destructor

NumptyAlert — Wed, 29 Nov 2006 19:32:10 +0100

You can't return a TPtrC to data that has to be destroyed.

Your code will work (although just have return *copy) but of course copy has to be deleted at some point.

So either you
- don't destroy the CRichText until the calling code has used the TPtrC
- make the function return a HBufC* instead of a TPtrC and thus transfer ownership of the HBufC to the calling code so it is its responsiblity to delete it.

You say the data has to be returned as a TPtrC, almost certainly it doesn't, you may just think that it does.

>>One option is to push the created HBufC into the cleanupstack and rename your method to functionLC, telling the caller that there is something to be cleaned up after calling this method.

Unless I've misunderstoof your posting you can't have one function push something to the cleanupstack and then expect the caller to call PopAndDestroyjust because the function it calls has a C in its name. What if FunctionLC() pushed 2 things, or 3 things or 100 things? How does the calling function know what to do?

Re: TPtrC and destructor

Andreas — Wed, 29 Nov 2006 19:23:37 +0100

One option is to push the created HBufC into the cleanupstack and rename your method to functionLC, telling the caller that there is something to be cleaned up after calling this method.

Another is to return the HBufC, renaming the method to functionL, and documenting that the caller is responsible for deleting the returned pointer.

Re: TPtrC and destructor

keanu — Wed, 29 Nov 2006 19:18:41 +0100

Thanks...
the situation is that I have a CRichText,in a function, that has to destroyed and the textual data in it have to be returned as TPtrC.
This is the code :

TPtrC function()
{
... // richtext is a CRichText, just pushed in the cleanupstack
...
...
HBufC* copy=richText->Read(0).Alloc();
CleanupStack::PopAndDestroy( richText );

return TPtrC(copy->Ptr(),copy->Length());
}

It works but IS THERE A BETTER WAY to do it ??

Re: TPtrC and destructor

NumptyAlert — Wed, 29 Nov 2006 19:04:26 +0100

A TPtrC points to data that is already existing, and thus is not responsible for either its creation nor its deletion (if either of those are necessary).

TPtrC and destructor

keanu — Wed, 29 Nov 2006 18:07:49 +0100