xmlvm-users

[xmlvm-users] memory management and return of an object

[Panayotis K. <pan...@pa...>]

I've seen that in the code produced by xmlvm, every time an object is  
returned, this object is at the same moment released.
Thus usually in properties we see something like:

return [[self propertyname] retain];

So, can we say that this is a general rule?
I mean, that in any case, no matter what, when the thin library obj-c  
layer is required to return an object, this object should be *always*  
retained?

Is this valid also for objects like usually retrieved with selectors  
like
[UIFont systemFontOfSize:fontsize]
?

I have made some tests with the last one, and even if I don't retain  
it, there is no segfault (which, ok, this doesn't mean anything).


So what is optimum (concerning memory management) ?

Thank you!

Re: [xmlvm-users] memory management and return of an object

[Arno P. <ar...@pu...>]

right now we have the rule that ownership of an object that is returned 
as a result of a method invocation is passed to the caller. That is why 
we have as a general rule a retain on references when returning them. 
The caller then decides what it wants to do with the reference. If the 
caller ignores the result (which the callee cannot know) it will do a 
release.

I will be adding a patch in the next few days that will get rid of 
NSAutoreleasePool. Those memory management rules won't change, but the 
code should be much more efficient.

Arno


On 3/11/10 5:20 AM, Panayotis Katsaloulis wrote:
>
> I've seen that in the code produced by xmlvm, every time an object is
> returned, this object is at the same moment released.
> Thus usually in properties we see something like:
>
> return [[self propertyname] retain];
>
> So, can we say that this is a general rule?
> I mean, that in any case, no matter what, when the thin library obj-c
> layer is required to return an object, this object should be *always*
> retained?
>
> Is this valid also for objects like usually retrieved with selectors
> like
> [UIFont systemFontOfSize:fontsize]
> ?
>
> I have made some tests with the last one, and even if I don't retain
> it, there is no segfault (which, ok, this doesn't mean anything).
>
>
> So what is optimum (concerning memory management) ?
>
> Thank you!
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] memory management and return of an object

[Panayotis K. <pan...@pa...>]

On 11 Μαρ 2010, at 6:09 ΜΜ, Arno Puder wrote:

>
> right now we have the rule that ownership of an object that is  
> returned
> as a result of a method invocation is passed to the caller. That is  
> why
> we have as a general rule a retain on references when returning them.
> The caller then decides what it wants to do with the reference. If the
> caller ignores the result (which the callee cannot know) it will do a
> release.
>
> I will be adding a patch in the next few days that will get rid of
> NSAutoreleasePool. Those memory management rules won't change, but the
> code should be much more efficient.
>
> Arno

So, practically it is always important to "retain" the object when  
creating the objective-c library connection with java, right?

I am asking this because I am working on a patch which will take care  
of nil objects returned by various property glue functions, and I want  
to make clear that it's a _rule_ to always retain an object before  
returning it.

Re: [xmlvm-users] memory management and return of an object

[Arno P. <ar...@pu...>]

as of now, it is the rule.

Arno


On 3/11/10 8:50 AM, Panayotis Katsaloulis wrote:
>
> On 11 Μαρ 2010, at 6:09 ΜΜ, Arno Puder wrote:
>
>>
>> right now we have the rule that ownership of an object that is
>> returned
>> as a result of a method invocation is passed to the caller. That is
>> why
>> we have as a general rule a retain on references when returning them.
>> The caller then decides what it wants to do with the reference. If the
>> caller ignores the result (which the callee cannot know) it will do a
>> release.
>>
>> I will be adding a patch in the next few days that will get rid of
>> NSAutoreleasePool. Those memory management rules won't change, but the
>> code should be much more efficient.
>>
>> Arno
>
> So, practically it is always important to "retain" the object when
> creating the objective-c library connection with java, right?
>
> I am asking this because I am working on a patch which will take care
> of nil objects returned by various property glue functions, and I want
> to make clear that it's a _rule_ to always retain an object before
> returning it.
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users