subject:"Autorelease Question"


Ok, you got me there...
But in my own defense it could still be to make sure that people are  
still able te retain the object without creating an overflow... ;-)


Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 21 Nov 2008, at 17:19, Jean-Daniel Dupas wrote:



Le 21 nov. 08 à 16:56, Filip van der Meeren a écrit :

Ok, lets say that [NSString string] creates a new object each and  
every time a framework/Application needs an empty string (like  
about a billion times). Then the RAM would be stuffed with empty  
string objects that are useless for everyone.
Now they have created a fix for this, one size fits all. They did  
this in a special way, by fixing there retainCount in a special  
subclass of NSString:


retainCount
Returns the receiver’s reference count.

- (NSUInteger)retainCount

Return Value
The receiver’s reference count.

Discussion
You rarely send a retainCount message; however, you might implement  
this method in a class to implement your own reference-counting  
scheme. For objects that never get released (that is, their release  
method does nothing), this method should returnUINT_MAX, as defined  
in .


The retainCount method does not account for any pending autorelease  
messages sent to the receiver.


This method is typically of limited value in debugging memory  
management issues.



I quote: "For objects that never get released, this method should  
return UINT_MAX". So where do you see your bug ?





Just here in your quote. UINT_MAX is a bug IMHO. It should be  
NSUIntegerMax as defined in 





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-21 Thread Jean-Daniel Dupas



Le 21 nov. 08 à 16:56, Filip van der Meeren a écrit :

Ok, lets say that [NSString string] creates a new object each and  
every time a framework/Application needs an empty string (like about  
a billion times). Then the RAM would be stuffed with empty string  
objects that are useless for everyone.
Now they have created a fix for this, one size fits all. They did  
this in a special way, by fixing there retainCount in a special  
subclass of NSString:


retainCount
Returns the receiver’s reference count.

- (NSUInteger)retainCount

Return Value
The receiver’s reference count.

Discussion
You rarely send a retainCount message; however, you might implement  
this method in a class to implement your own reference-counting  
scheme. For objects that never get released (that is, their release  
method does nothing), this method should returnUINT_MAX, as defined  
in .


The retainCount method does not account for any pending autorelease  
messages sent to the receiver.


This method is typically of limited value in debugging memory  
management issues.



I quote: "For objects that never get released, this method should  
return UINT_MAX". So where do you see your bug ?





Just here in your quote. UINT_MAX is a bug IMHO. It should be  
NSUIntegerMax as defined in 



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

But the docs also say "Another purpose for a class factory method is  
to ensure that a certain class (NSWorkspace, for example) vends a  
singleton instance".


Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 21 Nov 2008, at 17:12, Devon Ferns wrote:

The docs say autoreleased as he already said which may not always be  
true.


Devon

Filip van der Meeren wrote:

I quote: "For objects that never get released, this method should  
return UINT_MAX". So where do you see your bug ?

Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter
On 21 Nov 2008, at 16:44, mmalcolm crawford wrote:





I do, and I already filed a bug.

Cocoa Fundamentals Guide states:

Class Factory Methods

"Class factory methods are implemented by a class as a convenience  
for clients. They combine allocation and initialization in one  
step and return the created object autoreleased. These methods are  
of the form + (type)className... (where className excludes any  
prefix)."



It should probably not explicitly state "autoreleased" — it should  
simply state that — in accordance with standard memory management  
rules, in a reference counted environment — the receiver does not  
own the returned object.



mmalc


___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/dferns%40devonferns.com
This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question


I agree, but what would you have the documentation say ?

Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 21 Nov 2008, at 17:08, mmalcolm crawford wrote:



On Nov 21, 2008, at 7:56 AM, Filip van der Meeren wrote:

I quote: "For objects that never get released, this method should  
return UINT_MAX". So where do you see your bug ?



The bug is in the description, and the expectations it gives rise to.

There should be no need for any of this discussion.  As others have  
also said, you should be thinking simply in terms of ownership, not  
in terms of whether or not something is autoreleased per se.   
Changing the documentation will help prevent a counter-productive  
line of thinking.


mmalc



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-21 Thread Devon Ferns


The docs say autoreleased as he already said which may not always be true.

Devon

Filip van der Meeren wrote:



I quote: "For objects that never get released, this method should return 
UINT_MAX". So where do you see your bug ?



Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 21 Nov 2008, at 16:44, mmalcolm crawford wrote:





I do, and I already filed a bug.

Cocoa Fundamentals Guide states:

Class Factory Methods

"Class factory methods are implemented by a class as a convenience for 
clients. They combine allocation and initialization in one step and 
return the created object autoreleased. These methods are of the form 
+ (type)className... (where className excludes any prefix)."
 



It should probably not explicitly state "autoreleased" — it should 
simply state that — in accordance with standard memory management 
rules, in a reference counted environment — the receiver does not own 
the returned object.



mmalc



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/dferns%40devonferns.com

This email sent to [EMAIL PROTECTED]

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-21 Thread mmalcolm crawford



On Nov 21, 2008, at 7:56 AM, Filip van der Meeren wrote:

I quote: "For objects that never get released, this method should  
return UINT_MAX". So where do you see your bug ?



The bug is in the description, and the expectations it gives rise to.

There should be no need for any of this discussion.  As others have  
also said, you should be thinking simply in terms of ownership, not in  
terms of whether or not something is autoreleased per se.  Changing  
the documentation will help prevent a counter-productive line of  
thinking.


mmalc

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

Sorry to be this crude, but the documentation isn't created for  
beginners.
If I would have documentation for beginners, then I would never take  
look at it!

There are excellent books for beginners from Wrox and O'reilly...

Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 21 Nov 2008, at 16:45, Adam Leonard wrote:


Ok, yeah, it could call autorelease, but that would amount to a noop.
My problem with this documentation is that if I created a class that  
had a method just like the one you mentioned:


+ (Foo*)foo
{
static Foo *result = nil;
if(!result)
{
// Go freaky...

// Something like this
result = [[Foo alloc] initWithBytes:nil];
[result setThisRetainCountToMax];
}

return result;
}

This documentation would say this code is wrong for two reasons:
- It does not call autorelease
- Except for the first time it is called, it does not "combine  
allocation and initialization" (It just returns the singleton  
instance)


Now, I think this code is totally fine (though for an actual  
singleton, you would not set the retain count, but rather just  
override -retain, -release-, -autorelease, and -retainCount).


The rules of memory management suggest this code is fine too.

Therefore, I can only conclude that the generalization made by this  
page in the documentation (for beginners no less) is simply wrong.


Adam Leonard

On Nov 21, 2008, at 10:33AM, Filip van der Meeren wrote:



Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 21 Nov 2008, at 16:21, Adam Leonard wrote:

Ok, so my point with all this is that the documentation should not  
say that all class factory methods always return autoreleased  
objects because that is an implementation detail that (a) is not  
required by the memory management rules, (b) is something that the  
programmer should not care about, and (c) is not even true in the  
case of some methods, including [NSString string]


So I'll file a bug.



You will file a bug ?
I really do not see the bug here...

And for the very last time in this discussion... Where do you  
people get the fact that [NSString string] doesn't call autorelease ?
It might call it, and just have its retaincount fixed to a certain  
number...



Adam Leonard

On Nov 21, 2008, at 9:43AM, Kyle Sluder wrote:

On Thu, Nov 20, 2008 at 11:53 PM, Luke Hiesterman <[EMAIL PROTECTED] 
> wrote:
So thinking gets in the way of understanding and not thinking is  
the path to

enlightenment?


This is a bogus question.  You're thinking incorrectly.  There's a
reason the memory management rules don't explicitly call for  
things to
be autoreleased.  Following good OO principles, you shouldn't  
care how
things are memory managed within the framework; just make sure  
you're

doing the right thing and following the rules, and everyone's a
winner.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the  
list.

Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/adam%40caffeinatedcocoa.com

This email sent to [EMAIL PROTECTED]



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/filip%40code2develop.com

This email sent to [EMAIL PROTECTED]







___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

Ok, lets say that [NSString string] creates a new object each and  
every time a framework/Application needs an empty string (like about a  
billion times). Then the RAM would be stuffed with empty string  
objects that are useless for everyone.
Now they have created a fix for this, one size fits all. They did this  
in a special way, by fixing there retainCount in a special subclass of  
NSString:


retainCount
Returns the receiver’s reference count.

- (NSUInteger)retainCount

Return Value
The receiver’s reference count.

Discussion
You rarely send a retainCount message; however, you might implement  
this method in a class to implement your own reference-counting  
scheme. For objects that never get released (that is, their release  
method does nothing), this method should returnUINT_MAX, as defined in  
.


The retainCount method does not account for any pending autorelease  
messages sent to the receiver.


This method is typically of limited value in debugging memory  
management issues.



I quote: "For objects that never get released, this method should  
return UINT_MAX". So where do you see your bug ?



Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 21 Nov 2008, at 16:44, mmalcolm crawford wrote:



On Nov 21, 2008, at 7:33 AM, Filip van der Meeren wrote:

Ok, so my point with all this is that the documentation should not  
say that all class factory methods always return autoreleased  
objects because that is an implementation detail that (a) is not  
required by the memory management rules, (b) is something that the  
programmer should not care about, and (c) is not even true in the  
case of some methods, including [NSString string]

So I'll file a bug.

You will file a bug ?
I really do not see the bug here...


I do, and I already filed a bug.

Cocoa Fundamentals Guide states:

Class Factory Methods

"Class factory methods are implemented by a class as a convenience  
for clients. They combine allocation and initialization in one step  
and return the created object autoreleased. These methods are of the  
form + (type)className... (where className excludes any prefix)."



It should probably not explicitly state "autoreleased" — it should  
simply state that — in accordance with standard memory management  
rules, in a reference counted environment — the receiver does not  
own the returned object.



mmalc



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-21 Thread Adam Leonard


Ok, yeah, it could call autorelease, but that would amount to a noop.
My problem with this documentation is that if I created a class that  
had a method just like the one you mentioned:


+ (Foo*)foo
{
static Foo *result = nil;
if(!result)
{
// Go freaky...

// Something like this
result = [[Foo alloc] initWithBytes:nil];
[result setThisRetainCountToMax];
}

return result;
}

This documentation would say this code is wrong for two reasons:
- It does not call autorelease
- Except for the first time it is called, it does not "combine  
allocation and initialization" (It just returns the singleton instance)


Now, I think this code is totally fine (though for an actual  
singleton, you would not set the retain count, but rather just  
override -retain, -release-, -autorelease, and -retainCount).


The rules of memory management suggest this code is fine too.

Therefore, I can only conclude that the generalization made by this  
page in the documentation (for beginners no less) is simply wrong.


Adam Leonard

On Nov 21, 2008, at 10:33AM, Filip van der Meeren wrote:



Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 21 Nov 2008, at 16:21, Adam Leonard wrote:

Ok, so my point with all this is that the documentation should not  
say that all class factory methods always return autoreleased  
objects because that is an implementation detail that (a) is not  
required by the memory management rules, (b) is something that the  
programmer should not care about, and (c) is not even true in the  
case of some methods, including [NSString string]


So I'll file a bug.



You will file a bug ?
I really do not see the bug here...

And for the very last time in this discussion... Where do you people  
get the fact that [NSString string] doesn't call autorelease ?
It might call it, and just have its retaincount fixed to a certain  
number...



Adam Leonard

On Nov 21, 2008, at 9:43AM, Kyle Sluder wrote:

On Thu, Nov 20, 2008 at 11:53 PM, Luke Hiesterman <[EMAIL PROTECTED] 
> wrote:
So thinking gets in the way of understanding and not thinking is  
the path to

enlightenment?


This is a bogus question.  You're thinking incorrectly.  There's a
reason the memory management rules don't explicitly call for  
things to
be autoreleased.  Following good OO principles, you shouldn't care  
how
things are memory managed within the framework; just make sure  
you're

doing the right thing and following the rules, and everyone's a
winner.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/adam%40caffeinatedcocoa.com

This email sent to [EMAIL PROTECTED]



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/filip%40code2develop.com

This email sent to [EMAIL PROTECTED]





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-21 Thread mmalcolm crawford



On Nov 21, 2008, at 7:33 AM, Filip van der Meeren wrote:

Ok, so my point with all this is that the documentation should not  
say that all class factory methods always return autoreleased  
objects because that is an implementation detail that (a) is not  
required by the memory management rules, (b) is something that the  
programmer should not care about, and (c) is not even true in the  
case of some methods, including [NSString string]

So I'll file a bug.

You will file a bug ?
I really do not see the bug here...


I do, and I already filed a bug.

Cocoa Fundamentals Guide states:

Class Factory Methods

"Class factory methods are implemented by a class as a convenience for  
clients. They combine allocation and initialization in one step and  
return the created object autoreleased. These methods are of the form  
+ (type)className... (where className excludes any prefix)."



It should probably not explicitly state "autoreleased" — it should  
simply state that — in accordance with standard memory management  
rules, in a reference counted environment — the receiver does not own  
the returned object.



mmalc

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question



Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 21 Nov 2008, at 16:21, Adam Leonard wrote:

Ok, so my point with all this is that the documentation should not  
say that all class factory methods always return autoreleased  
objects because that is an implementation detail that (a) is not  
required by the memory management rules, (b) is something that the  
programmer should not care about, and (c) is not even true in the  
case of some methods, including [NSString string]


So I'll file a bug.



You will file a bug ?
I really do not see the bug here...

And for the very last time in this discussion... Where do you people  
get the fact that [NSString string] doesn't call autorelease ?
It might call it, and just have its retaincount fixed to a certain  
number...



Adam Leonard

On Nov 21, 2008, at 9:43AM, Kyle Sluder wrote:

On Thu, Nov 20, 2008 at 11:53 PM, Luke Hiesterman  
<[EMAIL PROTECTED]> wrote:
So thinking gets in the way of understanding and not thinking is  
the path to

enlightenment?


This is a bogus question.  You're thinking incorrectly.  There's a
reason the memory management rules don't explicitly call for things  
to
be autoreleased.  Following good OO principles, you shouldn't care  
how

things are memory managed within the framework; just make sure you're
doing the right thing and following the rules, and everyone's a
winner.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/adam%40caffeinatedcocoa.com

This email sent to [EMAIL PROTECTED]



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/filip%40code2develop.com

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-21 Thread Adam Leonard

Ok, so my point with all this is that the documentation should not say  
that all class factory methods always return autoreleased objects  
because that is an implementation detail that (a) is not required by  
the memory management rules, (b) is something that the programmer  
should not care about, and (c) is not even true in the case of some  
methods, including [NSString string]


So I'll file a bug.

Adam Leonard

On Nov 21, 2008, at 9:43AM, Kyle Sluder wrote:

On Thu, Nov 20, 2008 at 11:53 PM, Luke Hiesterman  
<[EMAIL PROTECTED]> wrote:
So thinking gets in the way of understanding and not thinking is  
the path to

enlightenment?


This is a bogus question.  You're thinking incorrectly.  There's a
reason the memory management rules don't explicitly call for things to
be autoreleased.  Following good OO principles, you shouldn't care how
things are memory managed within the framework; just make sure you're
doing the right thing and following the rules, and everyone's a
winner.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/adam%40caffeinatedcocoa.com

This email sent to [EMAIL PROTECTED]



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-21 Thread Kyle Sluder

On Thu, Nov 20, 2008 at 11:53 PM, Luke Hiesterman <[EMAIL PROTECTED]> wrote:
> So thinking gets in the way of understanding and not thinking is the path to
> enlightenment?

This is a bogus question.  You're thinking incorrectly.  There's a
reason the memory management rules don't explicitly call for things to
be autoreleased.  Following good OO principles, you shouldn't care how
things are memory managed within the framework; just make sure you're
doing the right thing and following the rules, and everyone's a
winner.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-21 Thread Jason Stephenson


Luke Hiesterman wrote:
So thinking gets in the way of understanding and not thinking is the 
path to enlightenment?


Yes, Grasshopper. You must stop thinking about the rules. You must stop 
thinking about the code. You must stop thinking about the computer. You 
must instead *become* the rules, become the code, become the computer. 
Only then is true enlightenment achieved.


Sorry, couldn't resist




Sent from my iPhone.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-20 Thread Filip van der Meeren



On 21 Nov 2008, at 04:55, Adam Leonard wrote:


See the Cocoa Fundamentals Guide:

"Class factory methods are implemented by a class as a convenience  
for clients. They combine allocation and initialization in one step  
and return the created object autoreleased. These methods are of  
the form + (type)className... (where className excludes any prefix)."


"autoreleased" !



Someone correct me if I am wrong about this, but the statement that  
convenience methods always return an autoreleased object is a  
generalization that is implementation specific and not always true.


As far as I can tell, it is not true in the case of [NSString  
string] on 10.5.


For example, try running this code:

NSString *string1 = [NSString string];
NSString *string2 = [[[NSString alloc]init]autorelease];

NSString *string3 = [NSString stringWithFormat:@"hello"];
NSString *string4 = [[[NSString  
alloc]initWithFormat:@"hello"]autorelease];


NSLog(@"string1: %p, string2: %p, string3: %p, string4:  
%p",string1,string2,string3,string4);


On my computer, string1 and string2 always point to the same address  
and string3 and string4 point to different addresses.




That is because all empty strings point to the same singleton.

Next, look at the retain counts of each. string1 and string2 return  
INT_MAX, while string3 and string4 return 1.


And if you really want, try:
int i;
for(i=0; i<1000; i++)
[string1 release]; //no crash

for(i=0; i<1000; i++)
[string3 release]; //CRASH




You should never release an object when you didn't retain it first.  
The fact that the [NSString string] has such a high retaincount is to  
make sure it will never get released; every program needs an empty  
string at some point...


All of this would leave me to believe that [NSString string] is NOT  
"combining allocation and initialization in one step and returning  
the created object autoreleased". Instead, it is likely implemented  
like this:


+ (id)string
{
return @"";
}


I would think of something like the following:

+ (NSString*)string
{
static NSString *result = nil;
if(!result)
{
// Go freaky...

// Something like this
result = [[NSConcreteString alloc] initWithBytes:nil];
[result setThisRetainCountToMax];
}

return result;
}




(i.e., returning an empty constant NSString)

Again, this makes sense. Why waste memory by having more than one  
empty string instance?


These are all implementation details, so I'm not suggesting that it  
is ok to ignore the memory management rules , but it is also an  
implementation detail as to when NSString decides to fulfill its end  
of the memory management agreement.


Another case where a class factory method that does call autorelease  
will not "return the created object autoreleased" is when its call  
to -init returns nil




There is no reason to assume that no autoreleasemessage was sent...
Messages to nil objects may happen according to the Objective-C  
language, will not call the method and automatically return nil, 0.0f,  
0...


For instance, One example given, +dataWithBytes:length:, is  
documented to return nil in cases when "the data object could not be  
created"


I think this is a bug in the documentation. I am curious to know  
what others think.




That isn't a bug, Objective-C reserves exceptions for extreme  
situations, that is in big contrast to other languages like C++ or C#  
that require more try-catch-blocks than actual code...
If it can't create the object for some reason, then it returns nil.  
And you the programmer have to check for the returnvalue not to be nil.
This method of working is much easier, just imagine that you would  
have to try-catch all these factorymethods/singletons !




Adam Leonard

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/filip%40code2develop.com

This email sent to [EMAIL PROTECTED]


Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-20 Thread Filip van der Meeren


They are.

On 21 Nov 2008, at 02:54, Klaus Backert wrote:



Am 20.11.2008 um 22:04 schrieb Adam Leonard:


Just to clarify:

They probably are identical, but not in the way everyone seems to  
be assuming.


To make sure I don't misrepresent anything, I'll just quote the rule:
"You take ownership of an object if you create it using a method  
whose name begins with "alloc" or "new" or contains "copy" (for  
example, alloc, newObject, or mutableCopy), or if you send it a  
retain message."


Nothing in that rule says or implies that objects you get through  
other methods are autoreleased.


See the Cocoa Fundamentals Guide:

"Class factory methods are implemented by a class as a convenience  
for clients. They combine allocation and initialization in one step  
and return the created object autoreleased. These methods are of the  
form + (type)className... (where className excludes any prefix)."


"autoreleased" !

Because of this the following statements are identical, as far as I  
can see:


NSString *blah = [[[NSString alloc] init] autorelease];
NSString *blah = [NSString string];

Aren't they?

Klaus

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/filip%40code2develop.com

This email sent to [EMAIL PROTECTED]


Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-20 Thread Kiel Gillard



On 21/11/2008, at 3:45 PM, Jim Correia wrote:


On Nov 20, 2008, at 11:36 PM, Kiel Gillard wrote:


While your discovery is interesting, maybe we're not supposed to  
know how NSString is implemented. Even if on your computer you do  
not get double free messages in your run log, a crash or whatever,  
I'm all for keeping the memory management rules simple and treating  
anything that doesn't contain "alloc] init...]" or "new]" as  
autoreleased.


The memory management rules are already simple. There are three rules.

Making up your own interpretations of them, such as "treating  
anything that doesn't contain 'alloc] init]' or 'new]' as  
autoreleased", is not only incorrect, but gets in the way of a  
fundamental understanding of how things work.


On their own is incorrect but in the context of the message I was  
replying to, it was not.


What happens to an object before it is handed to you is completely  
irrelevant. It doesn't matter. Thinking about what the method might  
have done with the object is a waste of mental effort. The only  
thing which is important is whether or not you are responsible for  
releasing the object.


I totally agree.




Jim

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/kiel.gillard%40gmail.com

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-20 Thread Luke Hiesterman

So thinking gets in the way of understanding and not thinking is the  
path to enlightenment?


Sent from my iPhone.

On Nov 20, 2008, at 8:45 PM, Jim Correia <[EMAIL PROTECTED]> wrote:


On Nov 20, 2008, at 11:36 PM, Kiel Gillard wrote:


On 21/11/2008, at 2:55 PM, Adam Leonard wrote:




I think this is a bug in the documentation. I am curious to know  
what others think.


While your discovery is interesting, maybe we're not supposed to  
know how NSString is implemented. Even if on your computer you do  
not get double free messages in your run log, a crash or whatever,  
I'm all for keeping the memory management rules simple and treating  
anything that doesn't contain "alloc] init...]" or "new]" as  
autoreleased.


The memory management rules are already simple. There are three rules.

Making up your own interpretations of them, such as "treating  
anything that doesn't contain 'alloc] init]' or 'new]' as  
autoreleased", is not only incorrect, but gets in the way of a  
fundamental understanding of how things work.


What happens to an object before it is handed to you is completely  
irrelevant. It doesn't matter. Thinking about what the method might  
have done with the object is a waste of mental effort. The only  
thing which is important is whether or not you are responsible for  
releasing the object.


Jim

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/luketheh%40apple.com

This email sent to [EMAIL PROTECTED]

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-20 Thread Jim Correia


On Nov 20, 2008, at 11:36 PM, Kiel Gillard wrote:


On 21/11/2008, at 2:55 PM, Adam Leonard wrote:




I think this is a bug in the documentation. I am curious to know  
what others think.


While your discovery is interesting, maybe we're not supposed to  
know how NSString is implemented. Even if on your computer you do  
not get double free messages in your run log, a crash or whatever,  
I'm all for keeping the memory management rules simple and treating  
anything that doesn't contain "alloc] init...]" or "new]" as  
autoreleased.


The memory management rules are already simple. There are three rules.

Making up your own interpretations of them, such as "treating anything  
that doesn't contain 'alloc] init]' or 'new]' as autoreleased", is not  
only incorrect, but gets in the way of a fundamental understanding of  
how things work.


What happens to an object before it is handed to you is completely  
irrelevant. It doesn't matter. Thinking about what the method might  
have done with the object is a waste of mental effort. The only thing  
which is important is whether or not you are responsible for releasing  
the object.


Jim

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-20 Thread Kiel Gillard



On 21/11/2008, at 2:55 PM, Adam Leonard wrote:


I think this is a bug in the documentation. I am curious to know  
what others think.


While your discovery is interesting, maybe we're not supposed to know  
how NSString is implemented. Even if on your computer you do not get  
double free messages in your run log, a crash or whatever, I'm all for  
keeping the memory management rules simple and treating anything that  
doesn't contain "alloc] init...]" or "new]" as autoreleased.


Kiel


Adam Leonard

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/kiel.gillard%40gmail.com

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-20 Thread Adam Leonard


See the Cocoa Fundamentals Guide:

"Class factory methods are implemented by a class as a convenience  
for clients. They combine allocation and initialization in one step  
and return the created object autoreleased. These methods are of the  
form + (type)className... (where className excludes any prefix)."


"autoreleased" !



Someone correct me if I am wrong about this, but the statement that  
convenience methods always return an autoreleased object is a  
generalization that is implementation specific and not always true.


As far as I can tell, it is not true in the case of [NSString string]  
on 10.5.


For example, try running this code:

NSString *string1 = [NSString string];
NSString *string2 = [[[NSString alloc]init]autorelease];

NSString *string3 = [NSString stringWithFormat:@"hello"];
NSString *string4 = [[[NSString  
alloc]initWithFormat:@"hello"]autorelease];


NSLog(@"string1: %p, string2: %p, string3: %p, string4:  
%p",string1,string2,string3,string4);


On my computer, string1 and string2 always point to the same address  
and string3 and string4 point to different addresses.


Next, look at the retain counts of each. string1 and string2 return  
INT_MAX, while string3 and string4 return 1.


And if you really want, try:
int i;
for(i=0; i<1000; i++)
[string1 release]; //no crash

for(i=0; i<1000; i++)
[string3 release]; //CRASH


All of this would leave me to believe that [NSString string] is NOT  
"combining allocation and initialization in one step and returning the  
created object autoreleased". Instead, it is likely implemented like  
this:


+ (id)string
{
return @"";
}

(i.e., returning an empty constant NSString)

Again, this makes sense. Why waste memory by having more than one  
empty string instance?


These are all implementation details, so I'm not suggesting that it is  
ok to ignore the memory management rules , but it is also an  
implementation detail as to when NSString decides to fulfill its end  
of the memory management agreement.


Another case where a class factory method that does call autorelease  
will not "return the created object autoreleased" is when its call to - 
init returns nil


For instance, One example given, +dataWithBytes:length:, is documented  
to return nil in cases when "the data object could not be created"



I think this is a bug in the documentation. I am curious to know what  
others think.



Adam Leonard

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-20 Thread Luke the Hiesterman

If you think about it, it becomes clear why convenience methods return  
autoreleased objects. As a heuristic, whoever retains an object should  
release it. Since you're having the class method perform an implicit  
retain (by calling alloc) then it needs to do a release. It obviously  
cannot release the object before returning it to you, so its only  
choice is to autorelease. When you call alloc yourself, then you are  
the one responsible for releasing at a later time.


Luke


On Nov 20, 2008, at 5:57 PM, Dave DeLong wrote:



On 20 Nov, 2008, at 6:54 PM, Klaus Backert wrote:


"Class factory methods are implemented by a class as a convenience  
for clients. They combine allocation and initialization in one step  
and return the created object autoreleased. These methods are of  
the form + (type)className... (where className excludes any prefix)."


"autoreleased" !

Because of this the following statements are identical, as far as I  
can see:


NSString *blah = [[[NSString alloc] init] autorelease];
NSString *blah = [NSString string];

Aren't they?


Yes.  They are identical.

Dave
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/luketheh%40apple.com

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-20 Thread Dave DeLong



On 20 Nov, 2008, at 6:54 PM, Klaus Backert wrote:


"Class factory methods are implemented by a class as a convenience  
for clients. They combine allocation and initialization in one step  
and return the created object autoreleased. These methods are of the  
form + (type)className... (where className excludes any prefix)."


"autoreleased" !

Because of this the following statements are identical, as far as I  
can see:


NSString *blah = [[[NSString alloc] init] autorelease];
NSString *blah = [NSString string];

Aren't they?


Yes.  They are identical.

Dave
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-20 Thread Klaus Backert



Am 20.11.2008 um 22:04 schrieb Adam Leonard:


Just to clarify:

They probably are identical, but not in the way everyone seems to  
be assuming.


To make sure I don't misrepresent anything, I'll just quote the rule:
"You take ownership of an object if you create it using a method  
whose name begins with "alloc" or "new" or contains "copy" (for  
example, alloc, newObject, or mutableCopy), or if you send it a  
retain message."


Nothing in that rule says or implies that objects you get through  
other methods are autoreleased.


See the Cocoa Fundamentals Guide:

"Class factory methods are implemented by a class as a convenience  
for clients. They combine allocation and initialization in one step  
and return the created object autoreleased. These methods are of the  
form + (type)className... (where className excludes any prefix)."


"autoreleased" !

Because of this the following statements are identical, as far as I  
can see:


NSString *blah = [[[NSString alloc] init] autorelease];
NSString *blah = [NSString string];

Aren't they?

Klaus

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-20 Thread Shawn Erickson

On Thu, Nov 20, 2008 at 1:04 PM, Adam Leonard <[EMAIL PROTECTED]> wrote:

> However, I think it *would* be a bad idea to call [[[NSWorkspace
> sharedWorkspace]retain]autorelease]
> A good singleton will override -retain, -release, and -autorelease to do
> nothing and return an appropriate value. But since you know it's a singleton
> (through appropriate documentation), you really shouldn't be doing any
> memory management with it.

IMHO it is never a bad idea to manage an objects life time using
proper retain/release semantics, you shouldn't care that it is a
singleton, you should treat it just as any other object. I say this
because it is possible that at some point in the future it may no
longer be a singleton (granted for ones documented by Apple to be a
singleton you could make such assumptions but still I think you should
treat it like any other object).

In my own code when I write or use a singleton (app-life long
singleton) of my own creation I always treat it as an object that I
need to manage the life time of. I even implement and maintain a
proper dealloc method in the singleton. This allows me the freedom
change it away from being a singleton in the future in the need
arises.

-Shawn
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-20 Thread Sherm Pendley


On Nov 20, 2008, at 4:04 PM, Adam Leonard wrote:

Now, I agree that it is mostly paranoia, but it is simply incorrect  
to say that any object you send autorelease to, or get through a  
method "whose name [DOES NOT] begins with "alloc" or "new" or  
contains "copy"" will be sent release in the next run loop.


Actually, it *is* correct to say that any object to which you send - 
autorelease will definitely will be sent a -release message the next  
time around the run loop. What is incorrect is to assume that it will  
necessarily be deallocated as a result of that -release message.


Thus, I sometimes see code that declares an instance variable  
"workspace," assigns it to [NSWorkspace sharedWorkspace] in an init  
method, then just uses it wherever, never bothering to retain it or  
anything.
While I think that's a pretty stupid way to save a little bit of  
typing


... especially given that there's an existing global variable NSApp  
for precisely that purpose. :-)


sherm--

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-20 Thread Chris Kane

I feel compelled to wade in here, to clarify a point.   I'll pick on  
Luke's comment but there were some other similar ones ...


On Nov 19, 2008, at 15:44, Luke the Hiesterman wrote:

It's simply not true that you have "no idea" when an object will be  
autoreleased. If you're on the main thread, you know that it will be  
released at the end of the runloop, and you know that your current  
method will return to its caller within the current runloop.



Regardless of "main thread", the autoreleased object will be released  
*when the current (at the time of the autorelease) pool is popped*.


NOT "will be released at the end of the runloop".  (If anything, that  
should be "at the end of the event loop", but of course that's still  
not correct -- see sentence #1.)  Autoreleased objects even on the  
main thread do not "survive until an event is finished being handled",  
which is another interpretation.  I think these come from a warped  
combination of the documentation's description of the AppKit having a  
pool around event handling, and the release happening when an  
autorelease pool is popped.


For example, if the AppKit were to add a pool in the -[NSApplication  
sendEvent:] call one usually sees in an event handling backtrace,  
autoreleased objects that ended up in that pool would get released  
when execution flow got back to -sendEvent:, which is not at long as  
the "end of the event loop".


I've had to debug several third party apps over the years which  
apparently assumed "the object would live at least until the end of  
the current event handling", which were tripped up when the lifetime  
was made shorter by a new pool being introduced somewhere.  And if  
it's an important app, we often can't introduce the pool we wanted to  
due to binary compatibility, which means everybody loses if it would  
have improved typical app performance.



Chris Kane
Cocoa Frameworks, Apple

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-20 Thread Adam Leonard


Just to clarify:

They probably are identical, but not in the way everyone seems to be  
assuming.


To make sure I don't misrepresent anything, I'll just quote the rule:
"You take ownership of an object if you create it using a method whose  
name begins with "alloc" or "new" or contains "copy" (for example,  
alloc, newObject, or mutableCopy), or if you send it a retain message."


Nothing in that rule says or implies that objects you get through  
other methods are autoreleased.


I did a quick test and found that [[[NSString alloc] init]  
autorelease] and [NSString string] return the SAME instance. Thus,  
they are probably optimized to return a constant empty string, as  
there is no reason to have multiple instances of an empty string  
taking up memory in an app.


Now, I agree that it is mostly paranoia, but it is simply incorrect to  
say that any object you send autorelease to, or get through a method  
"whose name [DOES NOT] begins with "alloc" or "new" or contains  
"copy"" will be sent release in the next run loop.



I'll offer a more practical example. NSWorkspace is documented to be a  
singleton, and +sharedWorkspace returns "*the* NSWorkspace object  
associated with the process," i.e., there will always be a single  
instance on NSWorkspace available that will never be deallocated  
(except by the OS when the process terminates).


Thus, I sometimes see code that declares an instance variable  
"workspace," assigns it to [NSWorkspace sharedWorkspace] in an init  
method, then just uses it wherever, never bothering to retain it or  
anything.
While I think that's a pretty stupid way to save a little bit of  
typing, the documentation makes it clear that there is nothing wrong  
with doing that, because this instance will not disappear.


However, I think it *would* be a bad idea to call [[[NSWorkspace  
sharedWorkspace]retain]autorelease]
A good singleton will override -retain, -release, and -autorelease to  
do nothing and return an appropriate value. But since you know it's a  
singleton (through appropriate documentation), you really shouldn't be  
doing any memory management with it.



Adam Leonard


On Nov 20, 2008, at 5:12AM, Alexander Spohr wrote:


Just to clarify:

Am 19.11.2008 um 23:43 schrieb Joseph Crawford:


NSString blah = [[[NSString alloc] init] autorelease]


is identical to


NSString blah = [NSString string];



atze

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/adam%40caffeinatedcocoa.com

This email sent to [EMAIL PROTECTED]



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-20 Thread Michael Ash

On Wed, Nov 19, 2008 at 11:48 PM, Kyle Sluder
<[EMAIL PROTECTED]> wrote:
> On Wed, Nov 19, 2008 at 11:38 PM, Michael Ash <[EMAIL PROTECTED]> wrote:
>> Seriously, this kind of hysteria does nobody any good. Nothing you do
>> besides explicitly releasing/draining an NSAutoreleasePool instance
>> that you explicitly created is going to drain the current autorelease
>> pool. You cannot make a call that "hits the top of the runloop", as a
>> call is going deeper into the stack by definition, and the top of the
>> runloop is shallower in the stack. If they run a nested runloop then
>> fine, those things nest.
>
> There's a reason that the documentation says "normally guaranteed,"
> not just "guaranteed":
>
> "A received object is normally guaranteed to remain valid within the
> method it was received in (exceptions include multithreaded
> applications and some Distributed Objects situations, although you
> must also take care if you modify the object from which you received
> the object)."
>
> http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/MemoryManagementRules.html

Irrelevant. This is talking about objects that you get back from
methods, not objects that you explicitly autorelease yourself.

>> Autorelease is *not* a signal that you no longer need an object.
>> That's what release does. Autorelease is a way to relinquish ownership
>> of an object *without destroying it right away*. The entire reason it
>> exists is so that you can safely and easily return objects to callers.
>> It would be utterly useless as a construct if such objects could
>> disappear at any moment.
>
> We're saying the same things here, I think.  The only issue I have is
> that in between returning an object and the caller being invoked --
> barring multithreading -- nothing else can happen, so your "reason" is
> incorrect.  Even if objects could disappear after any method call at
> all, that doesn't mean that they could disappear during the return.

That is true but that's not how it actually works. Also there is no
need to bar multithreading. The rules work equally well in a
multithreaded environment.

>> The lifetime of autorelease pools is well defined and highly
>> predictable. It is flat-out impossible for a Cocoa app which is not
>> experiencing some sort of memory smasher or other faulty behavior to
>> destroy an autoreleased object in the same scope in which it was
>> autoreleased, unless there is a very obvious call to destroy an
>> NSAutoreleasePool sitting right there in that code. Please, stop
>> spreading misinformation.
>
> Again, I defer to the documentation.  Perhaps it's because I'm working
> a lot with Distributed Objects that I'm being paranoid about object
> lifetimes.

You need to defer to the correct piece of the documentation. The only
reason that the documentation specifies "normally" is because you can
have methods which return objects which are not autoreleased, but
instead return a reference to an internal object or something similar.

To put this as simply as possible, consider the following skeleton:

- (void)method
{
id obj = [... autorelease]

...SOMETHING...

   return obj;
}

In any correctly written program, no matter WHAT you put in the
...SOMETHING..., you cannot cause obj to be destroyed. To put it
another way, if obj gets destroyed before reaching the return
statement then you have a serious memory management bug, and shuffling
around the position of the autorelease call will not save you.

What you described simply cannot happen in any correctly written
application. There are *similar* situations where you have to be more
careful, namely when you get a non-owned object back from a method.
For example:

- (void)method
{
id obj = [... foo]

...SOMETHING...

   return obj;
}

In this case you certainly can cause obj to be destroyed, depending on
exactly how 'foo' is implemented. For example, a call to -setFoo: may
result in its destruction. But that's not the same thing at all.

Mike
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-20 Thread Filip van der Meeren


Thats true, but we are discussing this topic on a apple mailing list...
So I do not think many people without OS X (and the  
Foundation.framework that comes along) are replying to this list.


On 20 Nov 2008, at 05:18, Michael Ash wrote:


On Wed, Nov 19, 2008 at 6:06 PM, Filip van der Meeren
<[EMAIL PROTECTED]> wrote:
I disagree, the retain, autorelease and release are all defined  
within the

Foundation framework.
And that is something that belongs together with the Objective-C  
language
(according to me); I know it does not need it to exist as a  
language, but

Objective-C is kind of useless without the Foundation framework...

I really don't see myself creating a NSObject interface each time I  
create a

terminal project! ;-)


It's useless without *a* foundation framework, but Foundation is not
the only one.

I did a great deal of productive work in Objective-C before ever
touching any libraries with a NeXT/Apple heritage. From that
perspective, everything that starts with NS is outside the language
and in libraries. From a pure Apple perspective it's not so clear.
Various Apple additions such as properties and garbage collection have
blurred the line even further. But still, ObjC can be quite useful
without Foundation.

Mike
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/filip%40code2develop.com

This email sent to [EMAIL PROTECTED]


Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-20 Thread Alexander Spohr


Just to clarify:

Am 19.11.2008 um 23:43 schrieb Joseph Crawford:


NSString blah = [[[NSString alloc] init] autorelease]


is identical to


NSString blah = [NSString string];



atze

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-20 Thread Jean-Daniel Dupas



Le 20 nov. 08 à 05:48, Kyle Sluder a écrit :

On Wed, Nov 19, 2008 at 11:38 PM, Michael Ash  
<[EMAIL PROTECTED]> wrote:

Seriously, this kind of hysteria does nobody any good. Nothing you do
besides explicitly releasing/draining an NSAutoreleasePool instance
that you explicitly created is going to drain the current autorelease
pool. You cannot make a call that "hits the top of the runloop", as a
call is going deeper into the stack by definition, and the top of the
runloop is shallower in the stack. If they run a nested runloop then
fine, those things nest.


There's a reason that the documentation says "normally guaranteed,"
not just "guaranteed":

"A received object is normally guaranteed to remain valid within the
method it was received in (exceptions include multithreaded
applications and some Distributed Objects situations, although you
must also take care if you modify the object from which you received
the object)."


Yes, that's because there is some exception:

"(exceptions include multithreaded
applications and some Distributed Objects situations, although you
must also take care if you modify the object from which you received
the object)."

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

On Wed, Nov 19, 2008 at 11:38 PM, Michael Ash <[EMAIL PROTECTED]> wrote:
> Seriously, this kind of hysteria does nobody any good. Nothing you do
> besides explicitly releasing/draining an NSAutoreleasePool instance
> that you explicitly created is going to drain the current autorelease
> pool. You cannot make a call that "hits the top of the runloop", as a
> call is going deeper into the stack by definition, and the top of the
> runloop is shallower in the stack. If they run a nested runloop then
> fine, those things nest.

There's a reason that the documentation says "normally guaranteed,"
not just "guaranteed":

"A received object is normally guaranteed to remain valid within the
method it was received in (exceptions include multithreaded
applications and some Distributed Objects situations, although you
must also take care if you modify the object from which you received
the object)."

http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/MemoryManagementRules.html

> Autorelease is *not* a signal that you no longer need an object.
> That's what release does. Autorelease is a way to relinquish ownership
> of an object *without destroying it right away*. The entire reason it
> exists is so that you can safely and easily return objects to callers.
> It would be utterly useless as a construct if such objects could
> disappear at any moment.

We're saying the same things here, I think.  The only issue I have is
that in between returning an object and the caller being invoked --
barring multithreading -- nothing else can happen, so your "reason" is
incorrect.  Even if objects could disappear after any method call at
all, that doesn't mean that they could disappear during the return.

> The lifetime of autorelease pools is well defined and highly
> predictable. It is flat-out impossible for a Cocoa app which is not
> experiencing some sort of memory smasher or other faulty behavior to
> destroy an autoreleased object in the same scope in which it was
> autoreleased, unless there is a very obvious call to destroy an
> NSAutoreleasePool sitting right there in that code. Please, stop
> spreading misinformation.

Again, I defer to the documentation.  Perhaps it's because I'm working
a lot with Distributed Objects that I'm being paranoid about object
lifetimes.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-19 Thread Michael Ash

On Wed, Nov 19, 2008 at 6:31 PM, Kyle Sluder
<[EMAIL PROTECTED]> wrote:
> On Wed, Nov 19, 2008 at 6:17 PM, Filip van der Meeren
> <[EMAIL PROTECTED]> wrote:
>> If you wait until the end of your method to autorelease the object, you are
>> leaving a whole range of possible memoryleaks open, since every call you
>> make between the allocation and release is a call that might throw an
>> exception (and we all know Objective-C uses memoryjumps from C).
>
> Gah!  You have no idea when an autoreleased object is going to be
> released.  What if a method call you make in between autoreleasing the
> object and really not needing it anymore hits the top of the runloop?
> Boom, your autoreleased object is gone.  As the documentation states,
> only use autorelease to signal that you no longer need an object.

What if a crocodile climbs out of your toilet and devours you while
you're busily working on your next Cocoa app?

Seriously, this kind of hysteria does nobody any good. Nothing you do
besides explicitly releasing/draining an NSAutoreleasePool instance
that you explicitly created is going to drain the current autorelease
pool. You cannot make a call that "hits the top of the runloop", as a
call is going deeper into the stack by definition, and the top of the
runloop is shallower in the stack. If they run a nested runloop then
fine, those things nest.

Autorelease is *not* a signal that you no longer need an object.
That's what release does. Autorelease is a way to relinquish ownership
of an object *without destroying it right away*. The entire reason it
exists is so that you can safely and easily return objects to callers.
It would be utterly useless as a construct if such objects could
disappear at any moment.

The lifetime of autorelease pools is well defined and highly
predictable. It is flat-out impossible for a Cocoa app which is not
experiencing some sort of memory smasher or other faulty behavior to
destroy an autoreleased object in the same scope in which it was
autoreleased, unless there is a very obvious call to destroy an
NSAutoreleasePool sitting right there in that code. Please, stop
spreading misinformation.

Mike
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-19 Thread Michael Ash

On Wed, Nov 19, 2008 at 6:06 PM, Filip van der Meeren
<[EMAIL PROTECTED]> wrote:
> I disagree, the retain, autorelease and release are all defined within the
> Foundation framework.
> And that is something that belongs together with the Objective-C language
> (according to me); I know it does not need it to exist as a language, but
> Objective-C is kind of useless without the Foundation framework...
>
> I really don't see myself creating a NSObject interface each time I create a
> terminal project! ;-)

It's useless without *a* foundation framework, but Foundation is not
the only one.

I did a great deal of productive work in Objective-C before ever
touching any libraries with a NeXT/Apple heritage. From that
perspective, everything that starts with NS is outside the language
and in libraries. From a pure Apple perspective it's not so clear.
Various Apple additions such as properties and garbage collection have
blurred the line even further. But still, ObjC can be quite useful
without Foundation.

Mike
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-19 Thread j o a r



On Nov 19, 2008, at 4:24 PM, Kyle Sluder wrote:


What prevents someone from manually running the runloop?



Nothing, but that wouldn't still create the problem that you proposed.  
Autorelease pools are stacked. Popping the autorelease pool for the  
inner runloop wouldn't have any effect on the autorelease pools higher  
up in the stack.


j o a r


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

Nothing prevents someone from running their own runloop, but I dealt  
with the most common case. Also, if you use your own  
NSAutoreleasePool, it's even easier to know when autoreleases will  
happen, because you're doing your own [pool drain];


Luke


On Nov 19, 2008, at 4:24 PM, Kyle Sluder wrote:

On Wed, Nov 19, 2008 at 6:44 PM, Luke the Hiesterman <[EMAIL PROTECTED] 
> wrote:

It's simply not true that you have "no idea" when an object will be
autoreleased. If you're on the main thread, you know that it will be
released at the end of the runloop, and you know that your current  
method

will return to its caller within the current runloop.


What prevents someone from manually running the runloop?

--Kyle Sluder


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-19 Thread mmalcolm crawford



On Nov 19, 2008, at 3:07 PM, DKJ wrote:

In general, if you retain an object, or use a either a "copy" or an  
"init..." method to obtain it, you need to release it yourself when  
you're done with it.


Otherwise, you can assume that the object will dispose of itself at  
some future time. But when this will happen is in practice  
unpredictable, which is why you need to retain the object before  
doing anything else with it.



This is at best misleading.

*Please*, don't try to reformulate the memory management rules when  
answering a question.
The more time goes by, the more I am convinced that most developers'  
confusion about memory management arises from other developers'  
misleading or incorrect answers to questions such as this.


Simply point to the canonical reference material (Kyle's answer  
provides a great model):



Read this document:
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concepts/ObjectOwnership.html#//apple_ref/doc/uid/2043-BEHDEDDB
Then read this one:
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/MemoryManagementRules.html
[...]



mmalc

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

On Wed, Nov 19, 2008 at 6:44 PM, Luke the Hiesterman <[EMAIL PROTECTED]> wrote:
> It's simply not true that you have "no idea" when an object will be
> autoreleased. If you're on the main thread, you know that it will be
> released at the end of the runloop, and you know that your current method
> will return to its caller within the current runloop.

What prevents someone from manually running the runloop?

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-19 Thread Carmen Cerino Jr.

Thank you all for your clarifications!

On Wed, Nov 19, 2008 at 6:53 PM, Andy Lee <[EMAIL PROTECTED]> wrote:
> On Nov 19, 2008, at 5:37 PM, Carmen Cerino Jr. wrote:
>>
>> I am not sure the best way to phrase this question into words, so I
>> will phrase it using example code.
>>
>> - (NSString*)foo
>> {
>>
>>   NSString blah = [NSString string];
>>
>>   .
>>
>>
>>   //Now do I do:
>>   return blah;
>>
>>   //Or:
>>   return [[blah retain] autorelease]];
>> }
>
> Both return statements are consistent with the memory management rules, but
> in this particular example, the retain and autorelease are superfluous.
>
> I wonder if you're asking because you've seen accessor methods that use the
> second variation?  For example, if you have a Person class with a "name"
> ivar:
>
> - (NSString *)name
> {
>return [[name retain] autorelease];
> }
>
> In this case an argument can be made for the retain and autorelease as
> opposed to just "return name;".  They protect from something like this:
>
> Person *aPerson = [[Person alloc] init];
> // ... some code which sets the person's name along the way ...
> NSString *aName = [aPerson name];
> [aPerson release];
>
> The [aPerson release] might cause aPerson to be deallocated, which might
> cause its name to be deallocated, which would cause aName to be a bad
> pointer.
>
> When I saw this pitfall, I panicked and thought I'd need to rewrite all my
> getter methods.  But it was Jens Ayton, I think, who noted that in practice
> one is very unlikely to run into this pitfall, so really it's a matter of
> personal preference.
>



-- 
Carmen C. Cerino
   University of Akron ACM Chapter President
   University of Akron Aux. Services Student Assistant
   Cell: 440.263.5057
   AIM: UAcodeweaver
   [ I <3 MACs ]
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-19 Thread Andy Lee


On Nov 19, 2008, at 5:37 PM, Carmen Cerino Jr. wrote:

I am not sure the best way to phrase this question into words, so I
will phrase it using example code.

- (NSString*)foo
{

   NSString blah = [NSString string];

   .


   //Now do I do:
   return blah;

   //Or:
   return [[blah retain] autorelease]];
}


Both return statements are consistent with the memory management  
rules, but in this particular example, the retain and autorelease are  
superfluous.


I wonder if you're asking because you've seen accessor methods that  
use the second variation?  For example, if you have a Person class  
with a "name" ivar:


- (NSString *)name
{
return [[name retain] autorelease];
}

In this case an argument can be made for the retain and autorelease as  
opposed to just "return name;".  They protect from something like this:


Person *aPerson = [[Person alloc] init];
// ... some code which sets the person's name along the way ...
NSString *aName = [aPerson name];
[aPerson release];

The [aPerson release] might cause aPerson to be deallocated, which  
might cause its name to be deallocated, which would cause aName to be  
a bad pointer.


When I saw this pitfall, I panicked and thought I'd need to rewrite  
all my getter methods.  But it was Jens Ayton, I think, who noted that  
in practice one is very unlikely to run into this pitfall, so really  
it's a matter of personal preference.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

It's simply not true that you have "no idea" when an object will be  
autoreleased. If you're on the main thread, you know that it will be  
released at the end of the runloop, and you know that your current  
method will return to its caller within the current runloop.  
Furthermore, you know that if you call a method from your method, that  
it will be executed within the current runloop. Unless you're dealing  
with asynchronous calls, it's actually fairly easy to know if you're  
going to fall out of the current runloop or not.


Luke


On Nov 19, 2008, at 3:31 PM, Kyle Sluder wrote:


On Wed, Nov 19, 2008 at 6:17 PM, Filip van der Meeren
<[EMAIL PROTECTED]> wrote:
If you wait until the end of your method to autorelease the object,  
you are
leaving a whole range of possible memoryleaks open, since every  
call you

make between the allocation and release is a call that might throw an
exception (and we all know Objective-C uses memoryjumps from C).


Gah!  You have no idea when an autoreleased object is going to be
released.  What if a method call you make in between autoreleasing the
object and really not needing it anymore hits the top of the runloop?
Boom, your autoreleased object is gone.  As the documentation states,
only use autorelease to signal that you no longer need an object.

As for exceptions, that's why we have @finally blocks.  Though since
exceptions in Cocoa are supposed to be reserved for programmer errors,
I would not worry all that much about exceptions and memory leaks.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/luketheh%40apple.com

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

On Wed, Nov 19, 2008 at 6:32 PM, Carmen Cerino Jr. <[EMAIL PROTECTED]> wrote:
> I guess I should also have included what spawned this question in the
> first place. I have read in a handful of places that you can
> guarantee, in the example case, that blah will exist until the end of
> function, and that sometime after the end of the scope of the function
> blah will be released. So if you don't know when it will be released,
> is there a possibility of it being released before control gets back
> to the caller so it can retain it?

The documentation used to be ambiguous on this point, but with the
addition of garbage collection has been rewritten to be more explicit:
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/chapter_3_section_5.html

"...the Application Kit automatically sets up an autorelease pool
scoped to the application's event cycle."

So when your app finishes processing a message from the WindowServer,
it flushes the autorelease pool.  When this happens is sort of
indeterminate, but can't happen in between the return statement and
the next evaluation in the caller, because there's no opportunity for
other code to execute that will run the runloop (which is where the
event cycle lives).

This is all operating under a single-threaded assumption.  If you
start multi-threading your app, YMMV.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-19 Thread DKJ



On 19-Nov-08, at 15:17 , Filip van der Meeren wrote:

If you already know you will autorelease the object and return it,  
then you should call the autorelease at the same moment you create  
the object.


NSString *str = [[[NSString alloc] init] autorelease];



Good point.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-19 Thread Carmen Cerino Jr.

I guess I should also have included what spawned this question in the
first place. I have read in a handful of places that you can
guarantee, in the example case, that blah will exist until the end of
function, and that sometime after the end of the scope of the function
blah will be released. So if you don't know when it will be released,
is there a possibility of it being released before control gets back
to the caller so it can retain it?

On Wed, Nov 19, 2008 at 6:19 PM, Kyle Sluder
<[EMAIL PROTECTED]> wrote:
> Read this document:
>
> http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concepts/ObjectOwnership.html#//apple_ref/doc/uid/2043-BEHDEDDB
>
> Then read this one:
>
> http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/MemoryManagementRules.html
>
> If you are just starting out, don't look for any patterns, just follow
> the rules.
>
> If you take ownership of an object, and want to return it and have
> nothing more to do with it, you need to relinquish ownership.  But if
> you just send it -release then it might go away before the caller gets
> it back, which is why -autorelease exists.
>
> --Kyle Sluder
>

-- 
Carmen C. Cerino
   University of Akron ACM Chapter President
   University of Akron Aux. Services Student Assistant
   Cell: 440.263.5057
   AIM: UAcodeweaver
   [ I <3 MACs ]
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

On Wed, Nov 19, 2008 at 6:17 PM, Filip van der Meeren
<[EMAIL PROTECTED]> wrote:
> If you wait until the end of your method to autorelease the object, you are
> leaving a whole range of possible memoryleaks open, since every call you
> make between the allocation and release is a call that might throw an
> exception (and we all know Objective-C uses memoryjumps from C).

Gah!  You have no idea when an autoreleased object is going to be
released.  What if a method call you make in between autoreleasing the
object and really not needing it anymore hits the top of the runloop?
Boom, your autoreleased object is gone.  As the documentation states,
only use autorelease to signal that you no longer need an object.

As for exceptions, that's why we have @finally blocks.  Though since
exceptions in Cocoa are supposed to be reserved for programmer errors,
I would not worry all that much about exceptions and memory leaks.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

Read this document:

http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concepts/ObjectOwnership.html#//apple_ref/doc/uid/2043-BEHDEDDB

Then read this one:

http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/MemoryManagementRules.html

If you are just starting out, don't look for any patterns, just follow
the rules.

If you take ownership of an object, and want to return it and have
nothing more to do with it, you need to relinquish ownership.  But if
you just send it -release then it might go away before the caller gets
it back, which is why -autorelease exists.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question


I feel the need to express one concern about this topic:

If you already know you will autorelease the object and return it,  
then you should call the autorelease at the same moment you create the  
object.


NSString *str = [[[NSString alloc] init] autorelease];

If you wait until the end of your method to autorelease the object,  
you are leaving a whole range of possible memoryleaks open, since  
every call you make between the allocation and release is a call that  
might throw an exception (and we all know Objective-C uses memoryjumps  
from C).


Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 20 Nov 2008, at 00:07, DKJ wrote:


If you've done this:

NSString *str = [NSString string];

then you can simply do this:

return str;

Whoever is getting the returned value should retain it, and then  
release it when they're done.


If you'd done this instead:

NSString *str = [[NSString alloc] init];

then you should do this:

return [str autorelease];

Once again, whoever is getting the returned value should retain it,  
and then release it when they're done.


In general, if you retain an object, or use a either a "copy" or an  
"init..." method to obtain it, you need to release it yourself when  
you're done with it.


Otherwise, you can assume that the object will dispose of itself at  
some future time. But when this will happen is in practice  
unpredictable, which is why you need to retain the object before  
doing anything else with it.


dkj


On 19-Nov-08, at 14:37 , Carmen Cerino Jr. wrote:


I am not sure the best way to phrase this question into words, so I
will phrase it using example code.

- (NSString*)foo
{

  NSString blah = [NSString string];

  .


  //Now do I do:
  return blah;

  //Or:
  return [[blah retain] autorelease]];
}
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/hatzicware%40shaw.ca

This email sent to [EMAIL PROTECTED]


=
Hatzic Intellectual Software
Victoria BC, Canada




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/filip%40code2develop.com

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

Agreed. libc can be considered a part of C, so Foundation is a part of  
Objective-C.


Luke

On Nov 19, 2008, at 3:06 PM, Filip van der Meeren wrote:

I disagree, the retain, autorelease and release are all defined  
within the Foundation framework.
And that is something that belongs together with the Objective-C  
language (according to me); I know it does not need it to exist as a  
language, but Objective-C is kind of useless without the Foundation  
framework...


I really don't see myself creating a NSObject interface each time I  
create a terminal project! ;-)



Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 19 Nov 2008, at 23:59, Shawn Erickson wrote:

On Wed, Nov 19, 2008 at 2:45 PM, Luke the Hiesterman <[EMAIL PROTECTED] 
> wrote:

This is really an objective-c question


Actually Cocoa memory management isn't and objective-c topic (unless
you are using GC then you get more toward a language level  
concept)...

retain/release/autorelease is a Cocoa concept.

-Shawn
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/filip%40code2develop.com

This email sent to [EMAIL PROTECTED]




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-19 Thread DKJ


If you've done this:

NSString *str = [NSString string];

then you can simply do this:

return str;

Whoever is getting the returned value should retain it, and then  
release it when they're done.


If you'd done this instead:

NSString *str = [[NSString alloc] init];

then you should do this:

return [str autorelease];

Once again, whoever is getting the returned value should retain it,  
and then release it when they're done.


In general, if you retain an object, or use a either a "copy" or an  
"init..." method to obtain it, you need to release it yourself when  
you're done with it.


Otherwise, you can assume that the object will dispose of itself at  
some future time. But when this will happen is in practice  
unpredictable, which is why you need to retain the object before doing  
anything else with it.


dkj


On 19-Nov-08, at 14:37 , Carmen Cerino Jr. wrote:


I am not sure the best way to phrase this question into words, so I
will phrase it using example code.

- (NSString*)foo
{

   NSString blah = [NSString string];

   .


   //Now do I do:
   return blah;

   //Or:
   return [[blah retain] autorelease]];
}
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/hatzicware%40shaw.ca

This email sent to [EMAIL PROTECTED]


=
Hatzic Intellectual Software
Victoria BC, Canada




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

I disagree, the retain, autorelease and release are all defined within  
the Foundation framework.
And that is something that belongs together with the Objective-C  
language (according to me); I know it does not need it to exist as a  
language, but Objective-C is kind of useless without the Foundation  
framework...


I really don't see myself creating a NSObject interface each time I  
create a terminal project! ;-)



Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 19 Nov 2008, at 23:59, Shawn Erickson wrote:

On Wed, Nov 19, 2008 at 2:45 PM, Luke the Hiesterman <[EMAIL PROTECTED] 
> wrote:

This is really an objective-c question


Actually Cocoa memory management isn't and objective-c topic (unless
you are using GC then you get more toward a language level concept)...
retain/release/autorelease is a Cocoa concept.

-Shawn
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/filip%40code2develop.com

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-19 Thread Shawn Erickson

On Wed, Nov 19, 2008 at 2:37 PM, Carmen Cerino Jr. <[EMAIL PROTECTED]> wrote:
> I am not sure the best way to phrase this question into words, so I
> will phrase it using example code.
>
> - (NSString*)foo
> {
>
>NSString blah = [NSString string];
>
>.
>
>
>//Now do I do:
>return blah;
>
>//Or:
>return [[blah retain] autorelease]];
> }

In the end either of the above are OK (assuming you add the "*" after
NSString)... the later return version is simply unneeded in the
example you have shown.

Of course [NSString string] is just an empty string and they are
immutable so your example doesn't make much sense.

-Shawn
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-19 Thread Shawn Erickson

On Wed, Nov 19, 2008 at 2:45 PM, Luke the Hiesterman <[EMAIL PROTECTED]> wrote:
> This is really an objective-c question

Actually Cocoa memory management isn't and objective-c topic (unless
you are using GC then you get more toward a language level concept)...
retain/release/autorelease is a Cocoa concept.

-Shawn
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question


It will not be contained in a NSAutoreleasePool per-se.
Lets say you create a console application, then you would have to make  
the choice, will I use the NSAutoreleasePool, or try it without (most  
likely you will, or you wouldn't be able to use autorelease or use any  
methods that use this method).
If you use the cocoa GUI and the NSApplicationMain that is in your  
"void main(args)" then you won't have to worry about this since the  
NSApplicationMain method will set up the pool for you.


Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 19 Nov 2008, at 23:52, Carmen Cerino Jr. wrote:



What do you me by comtain in an autorelease pool? Won't it be in one  
because blah was created using a factory method?

Sent from my iPhone

On Nov 19, 2008, at 5:47 PM, Filip van der Meeren <[EMAIL PROTECTED] 
> wrote:


As long as you do not contain the "blah" in a NSAutoreleasePool,  
then you do not have an issue...

Just use "return blah;".

Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 19 Nov 2008, at 23:37, Carmen Cerino Jr. wrote:


I am not sure the best way to phrase this question into words, so I
will phrase it using example code.

- (NSString*)foo
{

 NSString blah = [NSString string];

 .


 //Now do I do:
 return blah;

 //Or:
 return [[blah retain] autorelease]];
}
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/filip%40code2develop.com

This email sent to [EMAIL PROTECTED]




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question


Just one little addition to my previous mail; it is:

NSString *blah = [NSString string];

You forgot the star ;-)

Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 19 Nov 2008, at 23:47, Filip van der Meeren wrote:

As long as you do not contain the "blah" in a NSAutoreleasePool,  
then you do not have an issue...

Just use "return blah;".

Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 19 Nov 2008, at 23:37, Carmen Cerino Jr. wrote:


I am not sure the best way to phrase this question into words, so I
will phrase it using example code.

- (NSString*)foo
{

  NSString blah = [NSString string];

  .


  //Now do I do:
  return blah;

  //Or:
  return [[blah retain] autorelease]];
}
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/filip%40code2develop.com

This email sent to [EMAIL PROTECTED]




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

As long as you do not contain the "blah" in a NSAutoreleasePool, then  
you do not have an issue...

Just use "return blah;".

Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter

On 19 Nov 2008, at 23:37, Carmen Cerino Jr. wrote:


I am not sure the best way to phrase this question into words, so I
will phrase it using example code.

- (NSString*)foo
{

   NSString blah = [NSString string];

   .


   //Now do I do:
   return blah;

   //Or:
   return [[blah retain] autorelease]];
}
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/filip%40code2develop.com

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

This is really an objective-c question (and there is an obj-c list).  
Anyway, whenever you call a convenience class method +[NSString  
stringWithString:] as opposed to doing an alloc/init you're getting  
back an autoreleased object. So, if you're returning that value, it  
would make sense to simply return. Whoever called your method will  
have the responsibility of retaining. If you were interested in  
retaining, it wouldn't make sense to use the convenience method in the  
first place. Instead you would have done blah = [[NSString alloc]  
initWithString];


Luke


On Nov 19, 2008, at 2:37 PM, Carmen Cerino Jr. wrote:


I am not sure the best way to phrase this question into words, so I
will phrase it using example code.

- (NSString*)foo
{

   NSString blah = [NSString string];

   .


   //Now do I do:
   return blah;

   //Or:
   return [[blah retain] autorelease]];
}
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/luketheh%40apple.com

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease Question

2008-11-19 Thread Joseph Crawford


I believe that would better be done like this

- (NSString *)foo
{
NSString blah = [[[NSString alloc] init] autorelease]
...
return blah;
}

I might not be correct as I am a newbie too..

Thanks,
Joseph Crawford

On Nov 19, 2008, at 5:37 PM, Carmen Cerino Jr. wrote:


I am not sure the best way to phrase this question into words, so I
will phrase it using example code.

- (NSString*)foo
{

   NSString blah = [NSString string];

   .


   //Now do I do:
   return blah;

   //Or:
   return [[blah retain] autorelease]];
}
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/codebowl%40gmail.com

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Autorelease Question

2008-11-19 Thread Carmen Cerino Jr.

I am not sure the best way to phrase this question into words, so I
will phrase it using example code.

- (NSString*)foo
{

NSString blah = [NSString string];

.


//Now do I do:
return blah;

//Or:
return [[blah retain] autorelease]];
}
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question

2008-04-04 Thread Jens Alfke



On 3 Apr '08, at 5:50 PM, Adam Leonard wrote:

If you are writing a tool that links with Foundation and not AppKit,  
an autorelease pool is NOT created for you. As you saw in your first  
example, you need to explicitly create and destroy one whenever you  
are dealing with Foundation objects in a method.


It depends. At the outermost scope, like the main() method and things  
called directly by it, you have to create your own pools. But if your  
process uses NSRunLoop, that class ensures that everything it calls is  
in the context of an autorelease pool. So you don't have to worry  
about this when writing delegate/target methods for NSTimers,  
NSURLConnections, etc.


Of course, it doesn't hurt to add your own anyway, if you want; it's  
just a very small performance overhead.


—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question

2008-04-04 Thread Sherm Pendley

On Thu, Apr 3, 2008 at 10:18 PM, Dmitry Markman <[EMAIL PROTECTED]> wrote:

>
> On Apr 3, 2008, at 9:52 PM, Chris Suter wrote:
>
>  You're releasing things you shouldn't be. Take some time to read the
> > memory management documentation.
> >
>
> well, exactly
>
> so here is what I have
>
>NSString *nsFontName =   [NSString stringWithCString:fontName
> encoding:NSMacOSRomanStringEncoding];
>NSString *textString = [NSString stringWithCString:"Hello From
> Cocoa" encoding:NSMacOSRomanStringEncoding];
>NSGraphicsContext *context = [NSGraphicsContext
> graphicsContextWithGraphicsPort:cgContext flipped:TRUE];
>NSColor *cocoaColor = [NSColor colorWithCalibratedRed:r green:g
> blue:b alpha:alpha];
>NSFont *font = [NSFont fontWithName:nsFontName size:fontSize];
>NSMutableDictionary *stringAttributes = [NSMutableDictionary
> dictionaryWithCapacity:4];
>
> documentation

... hold on there. Now, normally I'm the last guy in the world to discourage
reading the docs. :-) But in this case, the memory-management guidelines
refer to the names of the methods you're using, not their descriptions in
the docs. So, the methods you're calling are:

+stringWithCString:encoding:
+graphicsContextWithGraphicsPort:flipped:
+colorWithCalibratedRed:green:blue:alpha:
+fontWithName:size:
+dictionaryWithCapacity:

None of those method names begin with +alloc or +new, or contain the word
"copy". So you don't need to release them; in fact, you must not do so. And
once you learn that simple pattern of method names, you'll know that for any
object you get back from any method, without having to look it up. The
answer is already right there in the method name itself.

Now, some of these are probably returning autoreleased objects, like
+dictionaryWithCapacity:. The font manager probably caches recently-used
font objects, and returns references to them from +fontWithName:size:.
Colors might refer to palette entries in some graphics modes. But you don't
need to be concerned with those details when writing your own code. The key
point here is that, for whatever reason, it's not your responsibility to
release the returned object. And, the fact that it's not your responsibility
to do so can be inferred from the name of the method itself, without
resorting to documentation.

As you've noted, you can sometimes get away with releasing something when
you're not supposed to. That's the nature of the beast - not guaranteed to
work doesn't mean guaranteed to not work, if you follow me.

sherm--
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question

2008-04-03 Thread Jens Alfke



On 3 Apr '08, at 7:50 PM, Dmitry Markman wrote:


1. I read all that documentation, please, enough about that, really


Reading it isn't enough, you have to _understand_ it. I know that  
sometimes it can take several readings before something makes sense.  
Usually after you've been burned by mistakes, it suddenly becomes  
clearer on the next reading :)


2.  I should follow the "alloc, new, copy or mutableCopy" rule. I  
should note
that I'm talking about creation methods not create/copy/get  
methods all of that

   notes about looking to the name (what in your name :-))  )
3. but I agree with Adam comment that the rule isn't 100% reliable  
and therefore isn't good enough


Err, it's been good enough for me for seven years and counting. I  
didn't see Adam say anything about rules not being good enough.


Methods that return objects either "give you a reference" that has to  
be released later, or they don't. You can tell from the name of the  
methods which ones they are. In the great majority of cases, the  
methods you call don't require you to deal with releasing the object.


The fact that there are autorelease pools is mostly an implementation  
detail. The fact that an object without 'alloc' or 'copy' in its name  
returns an object doesn't mean it autoreleased that object. The object  
could be an instance variable belonging to it, for example. It doesn't  
matter to you.


—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question

2008-04-03 Thread Adam Leonard


Sorry, you still are not really getting it.
There is nothing wrong with the documentation
You are not dealing with any exceptions to the rules

Cocoa memory management is quite unique and it can take a while to  
understand and get used to.
Just try to let everything sink in, read some open source Cocoa code,  
and eventually it should make sense.


3. but I agree with Adam comment that the rule isn't 100% reliable  
and therefore isn't good enough
And just to correct the record, that is not what I said at all :).  
There is no rule that says all objects not created with "alloc" "new"  
or "copy" are autoreleased. Once you understand how everything works  
and learn to follow the rules, you will understand why that does not  
make any difference whatsoever.


If you want me to clarify anything I have said, feel free to ask off  
list.


Adam Leonard
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question


well here is some summary
 1. I read all that documentation, please, enough about that, really
 2.  I should follow the "alloc, new, copy or mutableCopy" rule. I  
should note
 that I'm talking about creation methods not create/copy/get  
methods all of that

notes about looking to the name (what in your name :-))  )
 3. but I agree with Adam comment that the rule isn't 100% reliable  
and therefore isn't good enough

 4. following Jens advice
 create pool by myself
	and don't release object if they were created by non "alloc, new,  
copy or mutableCopy " (again not good enough)

and release the pool

thank you very much to all who answered



On Apr 3, 2008, at 10:32 PM, Chris Suter wrote:



On 04/04/2008, at 1:25 PM, Dmitry Markman wrote:


how can you explain that
  NSString *nsFontName =   [NSString stringWithCString:fontName  
encoding:NSMacOSRomanStringEncoding];

can be released, but
  NSString *textString = [NSString stringWithCString:"Hello  
From Cocoa" encoding:NSMacOSRomanStringEncoding];

can not
so what's the difference?


Neither of them should be released; there's no difference.


or yes there is a difference with one application crashes with another  
it doesn't

or you can see the difference between life and death :-))





Nobody wants to answer memory management questions on this list, not  
least because it's better said in the documentation. It's very  
comprehensively covered in the documentation so please take the time  
to read and understand them.


well, as I said few times documentation you mentioned simply isn't  
good enough. that's all
good documentation should say in every discussion paragraph:  that  
object is autoreleased, or isn't autoreleased

that's all
even for get/create/copy methods, because there are always exceptions  
(or will be)


computer language documentation shouldn't be like English (or any  
other language) grammar, where for every rule there are
more then one exceptions and that's, the rule :-)   (probably single  
rule without exception)






- Chris



Dmitry Markman

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question

2008-04-03 Thread Rohan Lloyd



On 4 Apr 2008, at 1:32 PM, Chris Suter wrote:


On 04/04/2008, at 1:25 PM, Dmitry Markman wrote:


how can you explain that
  NSString *nsFontName =   [NSString stringWithCString:fontName  
encoding:NSMacOSRomanStringEncoding];

can be released, but
  NSString *textString = [NSString stringWithCString:"Hello  
From Cocoa" encoding:NSMacOSRomanStringEncoding];

can not
so what's the difference?


Neither of them should be released; there's no difference.

Nobody wants to answer memory management questions on this list, not  
least because it's better said in the documentation. It's very  
comprehensively covered in the documentation so please take the time  
to read and understand them.


There was a previous thread that talked about this issue with the  
subject "Garbage collection - was Beginner with Cocoa". I'd suggest  
you read through that too. It starts here:


  http://lists.apple.com/archives/cocoa-dev/2008/Mar/msg01922.html

That thread gives a few good links to Apple's documentation on the  
subject. I'll provide the links here to make it easy:


  
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/chapter_3_section_5.html
  
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concepts/ObjectOwnership.html
  
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question

2008-04-03 Thread Dave Hersey

why do you think I didn't read all of that documentation? I did but,  
alas,  maybe I'm
not smart enough and I can't tell which object is autoreleased and  
which one not

that was in principle my initial question

I doubt that it's that you're not smart enough.

At the very least, you need to read about the Create Rule and the Get  
Rule if you're *only* confused about those:


http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html

However, I'd recommend going over the Apple Memory Management docs or  
the below references (which you may find clearer) until it gets boring  
and repetitive. If there's anything that you don't understand in these  
docs, they'll probably cost you a lot of development time.


Memory Management with Cocoa/WebObjects
http://stepwise.com/Articles/Technical/MemoryManagement.html

Very simple rules for memory management in Cocoa
http://stepwise.com/Articles/Technical/2001-03-11.01.html

This comes up a LOT on the list, so a search at http://www.cocoabuilder.com 
 may be helpful if you're still stuck.


- d

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question

2008-04-03 Thread Adam Leonard

You quoted the key memory management rule yourself from Hillegass's
book :)

You are making this too complicated. Just read this: http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/MemoryManagementRules.html#/
/apple_ref/doc/uid/2994

There are virtually no exceptions to those rules in the Cocoa
frameworks (if there are, they will be documented!)

looking at the retainCount property won't tell you about was
object autoreleased or not

Correct, you shouldn't care

documentation doesn't tell

because everything follows the rules

I posted my code you can see all 6 creation calls
And none of them have "alloc","new", or "copy" anywhere in the method
name, so NONE of them should be released by you.

The only think you need to release is the pool, because it was created
with -alloc

how can you explain that
NSString *nsFontName = [NSString stringWithCString:fontName
encoding:NSMacOSRomanStringEncoding];

can be released, but
NSString *textString = [NSString stringWithCString:"Hello
From Cocoa" encoding:NSMacOSRomanStringEncoding];

can not
so what's the difference?

Just because the first doesn't crash when it is released does not mean
that it *should* be released. (That's why I said you cannot know that
an object was actually autoreleased- but you should not care!). Just
assume both will be gone when you release the pool. If you want them
longer, retain them.

Whether an object is autoreleased by someone else is an implementation
detail. It can change in a future release. The fact is, neither of
those methods have "alloc" in the name, so neither need to be released
by you.

Don't think too much into all this. As long as you fulfill your side
of the contract, trust that Cocoa will fulfill its side.

Adam Leonard

thanks

On Apr 3, 2008, at 10:10 PM, Rob Keniger wrote:

On 04/04/2008, at 11:54 AM, Dmitry Markman wrote:

if I comment all those releases (excerpt [pool release])
then application won't crash

That's because all the methods you use to create the objects return
autoreleased objects which don't need to be released manually.

that probably means that some of the objects
(stringAttributes, font, cocoaColor, context, textString or
nsFontName)

were already in the pool and I shouldn't release them
also if I call retain for every above object and call release the
everything will be fine with [pool release]

but why should I retain them if I have no intention to share them?

Listen to what Chris says:

You're releasing things you shouldn't be. Take some time to read
the memory management documentation.

Read Apple's memory management documentation as well as the many,
many articles about Objective-C memory management on the web. Read
"Programming in Objective-C" by Stephen Kochan.

You are doing it wrong, that's why it's crashing.

--
Rob Keniger

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/dmarkman%40mac.com

This email sent to [EMAIL PROTECTED]

Dmitry Markman

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/adam%40caffeinatedcocoa.com

This email sent to [EMAIL PROTECTED]

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question

2008-04-03 Thread Chris Suter



On 04/04/2008, at 1:25 PM, Dmitry Markman wrote:


how can you explain that
   NSString *nsFontName =   [NSString stringWithCString:fontName  
encoding:NSMacOSRomanStringEncoding];

can be released, but
   NSString *textString = [NSString stringWithCString:"Hello  
From Cocoa" encoding:NSMacOSRomanStringEncoding];

can not
so what's the difference?


Neither of them should be released; there's no difference.

Nobody wants to answer memory management questions on this list, not  
least because it's better said in the documentation. It's very  
comprehensively covered in the documentation so please take the time  
to read and understand them.


- Chris



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question


thanks
as  Adam Leonard said ([EMAIL PROTECTED]) (BTW in reply to my  
note)



Also, a small note:



Aaron Hillehass in his book, said that if object wasn't created with
alloc, new, copy or mutableCopy then that object will be added
to the default autorelease pool


Reread that sentence in Hillegass's book.It says to "assume...[the  
object] is in the autorelease pool". It will not always be the case  
that an object not created with alloc, copy, etc. will be in an  
autorelease pool. It might be a singleton or cached in some way.  
These are usually implementation details, but just watch out.


and I agree with him.
so as you can see I'm very well aware about "alloc, new, copy or  
mutableCopy"

and my initial question was

How can I tell is there autorelease pool in my application?
because if it does exist I don't have to create my own

and as Jens answered, there is no way to say


On Apr 3, 2008, at 10:24 PM, stephen joseph butler wrote:

On Thu, Apr 3, 2008 at 9:18 PM, Dmitry Markman <[EMAIL PROTECTED]>  
wrote:


I just thought that all those 5 methods are CREATION methods they  
are not

GET methods
so how do I know which one I should release?



You're way over analyzing this. Does the *method name* contain the  
words
alloc, new, copy or mutableCopy? If yes, then call release.  
Otherwise, it

will be put in the autorelease pool.

You're going into the *documentation* and looking for those words. The
paradigm is based on method names, however, so that you don't have  
to go to

the documentation while you're coding.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/dmarkman%40mac.com

This email sent to [EMAIL PROTECTED]


Dmitry Markman

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question


why do you think I didn't read all of that documentation?
I did
but, alas,  maybe I'm not smart enough and I
can't tell which object is autoreleased and which one not

that was in principle my initial question

looking at the retainCount property won't tell you about was
object autoreleased or not


documentation doesn't tell
I posted my code you can see all 6 creation calls

how can you explain that
NSString *nsFontName =   [NSString stringWithCString:fontName  
encoding:NSMacOSRomanStringEncoding];

can be released, but
NSString *textString = [NSString stringWithCString:"Hello  
From Cocoa" encoding:NSMacOSRomanStringEncoding];

can not
so what's the difference?


thanks


On Apr 3, 2008, at 10:10 PM, Rob Keniger wrote:



On 04/04/2008, at 11:54 AM, Dmitry Markman wrote:

if I comment all those releases (excerpt [pool release])
then application won't crash


That's because all the methods you use to create the objects return  
autoreleased objects which don't need to be released manually.



that probably means that some of the objects
(stringAttributes, font, cocoaColor, context, textString or  
nsFontName)

were already in the pool and I shouldn't release them
also if I call retain for every above object and call release the  
everything will be fine with [pool release]

but why should I retain them if I have no intention to share them?



Listen to what Chris says:

You're releasing things you shouldn't be. Take some time to read  
the memory management documentation.



Read Apple's memory management documentation as well as the many,  
many articles about Objective-C memory management on the web. Read  
"Programming in Objective-C" by Stephen Kochan.


You are doing it wrong, that's why it's crashing.

--
Rob Keniger



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/dmarkman%40mac.com

This email sent to [EMAIL PROTECTED]


Dmitry Markman

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question

2008-04-03 Thread stephen joseph butler

On Thu, Apr 3, 2008 at 9:18 PM, Dmitry Markman <[EMAIL PROTECTED]> wrote:

> I just thought that all those 5 methods are CREATION methods they are not
> GET methods
> so how do I know which one I should release?

You're way over analyzing this. Does the *method name* contain the words
alloc, new, copy or mutableCopy? If yes, then call release. Otherwise, it
will be put in the autorelease pool.

You're going into the *documentation* and looking for those words. The
paradigm is based on method names, however, so that you don't have to go to
the documentation while you're coding.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question



On Apr 3, 2008, at 9:52 PM, Chris Suter wrote:

You're releasing things you shouldn't be. Take some time to read the  
memory management documentation.


well, exactly

so here is what I have

NSString *nsFontName =   [NSString stringWithCString:fontName  
encoding:NSMacOSRomanStringEncoding];
NSString *textString = [NSString stringWithCString:"Hello  
From Cocoa" encoding:NSMacOSRomanStringEncoding];
NSGraphicsContext *context = [NSGraphicsContext  
graphicsContextWithGraphicsPort:cgContext flipped:TRUE];
NSColor *cocoaColor = [NSColor colorWithCalibratedRed:r  
green:g blue:b alpha:alpha];

NSFont *font = [NSFont fontWithName:nsFontName size:fontSize];
NSMutableDictionary *stringAttributes = [NSMutableDictionary  
dictionaryWithCapacity:4];



documentation for
+[NSString  
stringWithCString:encoding 
]no word about  
releasing / retaining


+[NSGraphicsContext graphicsContextWithGraphicsPort: flipped:]
it says  "Return Value:   The created NSGraphicsContext object or nil  
if the object could not be created."

so I suppose I should release it

+[NSColor colorWithCalibratedRed:green:blue:alpha];  no word about  
releasing / retaining
it says: "Return Value The color object." so I suppose I should  
release it, because it returns new object


+[NSFont fontWithName: size:fontSize];
from documenattion
"Return Value
A font object for the specified name and size.
Discussion
The fontName is a fully specified family-face name, such as Helvetica- 
BoldOblique or Times-Roman. The fontSize is equivalent to using a font  
matrix of [fontSize 0 0 fontSize 0 0] withfontWithDescriptor:size:. If  
you use a fontSize of 0.0, this method uses the default User Font size.
Fonts created with this method automatically flip themselves in  
flipped views. This method is the preferred means for creating fonts."

so it said "created" so I thought I should release it

and finally

+[NSMutableDictionary dictionaryWithCapacity]
Return Value
A new mutable dictionary with enough allocated memory to hold numItems  
entries.

it says "NEW" so I suppose I should release it

I just thought that all those 5 methods are CREATION methods they are  
not GET methods

so how do I know which one I should release?

after playing with those releases I found that only
[font release];
[nsFontName release];
are harmless

it looks like that they were cached

it doesn't make any sense to me (at least yet :-(   )

it looks like that solution is to go to GarbageCollection and forget  
about

pools/release e.t.c
that's what Apple wants? :-))

Dmitry Markman

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question

2008-04-03 Thread Rob Keniger



On 04/04/2008, at 11:54 AM, Dmitry Markman wrote:

if I comment all those releases (excerpt [pool release])
then application won't crash


That's because all the methods you use to create the objects return  
autoreleased objects which don't need to be released manually.



that probably means that some of the objects
(stringAttributes, font, cocoaColor, context, textString or  
nsFontName)

were already in the pool and I shouldn't release them
also if I call retain for every above object and call release the  
everything will be fine with [pool release]

but why should I retain them if I have no intention to share them?



Listen to what Chris says:

You're releasing things you shouldn't be. Take some time to read the  
memory management documentation.



Read Apple's memory management documentation as well as the many, many  
articles about Objective-C memory management on the web. Read  
"Programming in Objective-C" by Stephen Kochan.


You are doing it wrong, that's why it's crashing.

--
Rob Keniger



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question


Just addition to the previous email

On Apr 3, 2008, at 9:45 PM, Dmitry Markman wrote:



   [stringAttributes release];
   [font release];
   [cocoaColor release];
   [context release];
   [textString release];
   [nsFontName release];
   [pool release];




if I comment all those releases (excerpt [pool release])
then application won't crash

that probably means that some of the objects
(stringAttributes, font, cocoaColor, context, textString or nsFontName)
were already in the pool and I shouldn't release them
also if I call retain for every above object and call release the  
everything will be fine with [pool release]

but why should I retain them if I have no intention to share them?



thanks


Dmitry Markman

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question

2008-04-03 Thread Chris Suter



On 04/04/2008, at 12:45 PM, Dmitry Markman wrote:


thanks a lot for the answer, Jens

but that how my problem began :-)
from creating my own NSAutoreleasePool

here is my code

[snip]

You're releasing things you shouldn't be. Take some time to read the  
memory management documentation.


- Chris



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question


thanks a lot for the answer, Jens

but that how my problem began :-)
from creating my own NSAutoreleasePool

here is my code

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSString *nsFontName =   [NSString stringWithCString:fontName  
encoding:NSMacOSRomanStringEncoding];
NSString *textString = [NSString stringWithCString:"Hello  
From Cocoa" encoding:NSMacOSRomanStringEncoding];

NSPoint p = NSMakePoint(qdX, qdY);
NSGraphicsContext *oldContext = [NSGraphicsContext  
currentContext];
NSGraphicsContext *context = [NSGraphicsContext  
graphicsContextWithGraphicsPort:cgContext flipped:TRUE];

[NSGraphicsContext setCurrentContext : context];
NSColor *cocoaColor = [NSColor colorWithCalibratedRed:r  
green:g blue:b alpha:alpha];

NSFont *font = [NSFont fontWithName:nsFontName size:fontSize];
NSMutableDictionary *stringAttributes = [NSMutableDictionary  
dictionaryWithCapacity:4];

[stringAttributes setObject:font forKey:NSFontAttributeName];
[stringAttributes setObject:cocoaColor  
forKey:NSForegroundColorAttributeName];


[textString drawAtPoint:p withAttributes:stringAttributes];

[NSGraphicsContext setCurrentContext : oldContext];

[stringAttributes release];
[font release];
[cocoaColor release];
[context release];
[textString release];
[nsFontName release];
[pool release];

and application crashes with the stack

(gdb) bt 10
#0  0x91a156e8 in objc_msgSend ()
#1  0x94108fdf in NSPopAutoreleasePool ()
#2  0x10a033d6 in Cocoa_DrawText (color=0xbfffebf6,  
fontName=0x10a38604 "Times New Roman Bold", fontSize=24, qdX=38,  
qdY=50, text=0x10a385f8 "Hello World", alpha=1) at ../models/ 
AcDc/../../../models/AcDc/src/acdc/acdc.cpp:1691
#3  0x10a034b2 in CAcdc::DoUpdate (this=0xe661760) at ../models/ 
AcDc/../../../models/AcDc/src/acdc/acdc.cpp:1724

#4  0x10a09f22 in CAcdc::ReadData (this=0xe661760) at ../



that's how I started to look at it
also I'm not sure I have to release all of those objects, like  
cocoaColor, font e.t.c.


I became suspicious when
NSString *nsFontName =   [NSString stringWithCString:fontName  
encoding:NSMacOSRomanStringEncoding];

didn't complain about absence of the pool (if I didn't create my own)


Note: our main application isn't linked against Cocoa framework at all
it linked against CoreFoundation, QuickTime, Carbon, CoreServices,  
ApplicationServices frameworks

our application uses 10.4 SDK
and as far as I can see none of those frameworks (in 10.4u.sdk) don't  
use Foundation or AppKit


however our bundle linked against Cocoa framework

thanks










On Apr 3, 2008, at 8:47 PM, Jens Alfke wrote:



On 3 Apr '08, at 5:07 PM, Robert Claeson wrote:

The default autorelease pool is created in the .m  
file of a newly created project. If you have messed around too much  
with that file, you might have deleted it.


There's not a "default" autorelease pool. They form a stack, and get  
pushed and popped dynamically.


It's true that the very outermost pool on the main thread is created  
in main(); but hopefully nothing your app is doing dynamically will  
end up using that pool, because objects autoreleased into it will  
hang around until the app quits.


But usually when your app code is running, it's responding to events  
or timers or other actions under the control of the runloop, so the  
topmost autorelease pool is a temporary one created by the runloop  
for the duration of that call (and cleaned up as soon as your code  
returns.)


To answer the original question: I don't think you can tell whether  
there's an autorelease pool active. But it doesn't matter: if you're  
doing anything that could autorelease objects, and there might not  
be a pool already, create your own by calling [NSAutoreleasePool  
new] beforehand and [pool drain] afterwards.


—Jens


Dmitry Markman

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question

2008-04-03 Thread Adam Leonard

Hi,
This is all explained for you here:
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concepts/AutoreleasePools.html
and here: http://developer.apple.com/documentation/Cocoa/Conceptual/CarbonCocoaDoc/Articles/WrapperFunctions.html#/
/apple_ref/doc/uid/20002398-TP1

To summarize:
If you are writing a tool that links with Foundation and not AppKit,
an autorelease pool is NOT created for you. As you saw in your first
example, you need to explicitly create and destroy one whenever you
are dealing with Foundation objects in a method.

If you are writing an application that links with AppKit (and
Foundation), autorelease pools are managed for you, and one should
always exist when calling any obj-c method. Usually, they are created
before dealing with an event, and destroyed after everything returns
to main. (This all assumes you keep the main function generated by the
xcode template intact)

If you are writing an application in Carbon that uses AppKit, it
depends. I assume you are doing this in your second example, and
calling NSApplicationLoad somewhere. Usually, it is better just to
always explicitly create an autorelease pool, but it is created for
you in some contexts, as you are seeing.
I don't think there is any public API for checking if an autorelease
pool is in place before, but if you are working with a complex carbon
situation, it never hurts to just create your own to be sure.

Also, a small note:

Aaron Hillehass in his book, said that if object wasn't created with
alloc, new, copy or mutableCopy then that object will be added
to the default autorelease pool

Reread that sentence in Hillegass's book.It says to "assume...[the
object] is in the autorelease pool". It will not always be the case
that an object not created with alloc, copy, etc. will be in an
autorelease pool. It might be a singleton or cached in some way. These
are usually implementation details, but just watch out.

Adam Leonard
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question

2008-04-03 Thread Chris Suter



On 04/04/2008, at 11:47 AM, Jens Alfke wrote:

It's true that the very outermost pool on the main thread is created  
in main();


I don't think that's normally the case. For a Cocoa application  
created by the Xcode template, it won't create an autorelease pool for  
you. Obviously, there won't be one created for you in the template for  
a Carbon application.


I suspect the reason for the observed difference reported in the  
original e-mail was because the code either wasn't running in the  
Carbon application, or was running as part of the event loop—I believe  
that an autorelease pool will be created for Carbon event loops.


To answer the original question: I don't think you can tell whether  
there's an autorelease pool active. But it doesn't matter: if you're  
doing anything that could autorelease objects, and there might not  
be a pool already, create your own by calling [NSAutoreleasePool  
new] beforehand and [pool drain] afterwards.


I think you mean [pool release], not [pool drain].

- Chris



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question

2008-04-03 Thread Jens Alfke



On 3 Apr '08, at 5:07 PM, Robert Claeson wrote:

The default autorelease pool is created in the .m file  
of a newly created project. If you have messed around too much with  
that file, you might have deleted it.


There's not a "default" autorelease pool. They form a stack, and get  
pushed and popped dynamically.


It's true that the very outermost pool on the main thread is created  
in main(); but hopefully nothing your app is doing dynamically will  
end up using that pool, because objects autoreleased into it will hang  
around until the app quits.


But usually when your app code is running, it's responding to events  
or timers or other actions under the control of the runloop, so the  
topmost autorelease pool is a temporary one created by the runloop for  
the duration of that call (and cleaned up as soon as your code returns.)


To answer the original question: I don't think you can tell whether  
there's an autorelease pool active. But it doesn't matter: if you're  
doing anything that could autorelease objects, and there might not be  
a pool already, create your own by calling [NSAutoreleasePool new]  
beforehand and [pool drain] afterwards.


—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question


Hi, Hamish
or yes I'm pretty sure
I can see result on the screen

code in question is called from the mac os x bundle
neither bundle project nor project of the main application
have any NSAutoreleasePool creation

in fact there is only one file that include 

On Apr 3, 2008, at 8:19 PM, Hamish Allan wrote:

On Fri, Apr 4, 2008 at 1:03 AM, Dmitry Markman <[EMAIL PROTECTED]>  
wrote:



but from other hand in the complex Carbon application, where I never
explicitly created NSAutoreleasePool object
I can call
   NSString *textString = [NSString  
stringWithCString:"Hello From

Cocoa" encoding:NSMacOSRomanStringEncoding];
without any warnings about _NSAutoreleaseNoPool


You are quite sure this code is being executed?


so I suppose default NSAutoreleasePool was created for me


I don't think it ever gets created for you; XCode can generate code
that creates it; if so, you should be able to find "NSAutoreleasePool"
with a project-wide search.

Hamish


Dmitry Markman

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question

2008-04-03 Thread Hamish Allan

On Fri, Apr 4, 2008 at 1:03 AM, Dmitry Markman <[EMAIL PROTECTED]> wrote:

>  but from other hand in the complex Carbon application, where I never
> explicitly created NSAutoreleasePool object
>  I can call
> NSString *textString = [NSString stringWithCString:"Hello From
> Cocoa" encoding:NSMacOSRomanStringEncoding];
>  without any warnings about _NSAutoreleaseNoPool

You are quite sure this code is being executed?

>  so I suppose default NSAutoreleasePool was created for me

I don't think it ever gets created for you; XCode can generate code
that creates it; if so, you should be able to find "NSAutoreleasePool"
with a project-wide search.

Hamish
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question


Hi, Robert
thanks for your answer

our project never had that file
as matter of fact project  in question doesn't have any .m files at all
(we just compile file with the Cocoa code with -x objective-c++   
compiler flag)


 thanks
 dm


On Apr 3, 2008, at 8:07 PM, Robert Claeson wrote:



On 4 Apr 2008, at 02:03, Dmitry Markman wrote:

Hi
How can I tell that default autorelease pool exists?


Dmitry

The default autorelease pool is created in the .m file  
of a newly created project. If you have messed around too much with  
that file, you might have deleted it.


The interesting lines are:

int main (int argc, const char * argv[]) {
   NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
   ...
   [pool drain];
}


Dmitry Markman

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Autorelease question

2008-04-03 Thread Robert Claeson



On 4 Apr 2008, at 02:03, Dmitry Markman wrote:

Hi
How can I tell that default autorelease pool exists?


Dmitry

The default autorelease pool is created in the .m file  
of a newly created project. If you have messed around too much with  
that file, you might have deleted it.


The interesting lines are:

int main (int argc, const char * argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
...
[pool drain];
}
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Autorelease question