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,
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
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
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
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
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
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 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
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
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
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
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
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
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
On Nov 21, 2008, at 7:59 AM, Filip van der Meeren wrote:
Sorry to be this crude, but the documentation isn't created for
beginners.
Sorry to be blunt, but some of it is. And Cocoa Fundamentals in
particular is intended for newcomers to the platform and comparative
newcomers to
On Nov 20, 2008, at 11:53 PM, Luke Hiesterman wrote:
So thinking gets in the way of understanding and not thinking is the
path to enlightenment?
Not thinking about *irrelevancies* is the path to enlightenment. It
allows you to focus on the things you actually *do* need to understand.
On Nov 21, 2008, at 10:33 AM, Filip van der Meeren wrote:
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)
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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]];
}
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.
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
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
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
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
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;
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
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];
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
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
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
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
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
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.
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
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
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
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
{
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
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
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
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
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
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
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
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
Hi
How can I tell that default autorelease pool exists?
here is why I ask
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
and indeed, in the simple guiless Cocoa application
if I
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
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 Cocoa/Cocoa.h
On Apr 3, 2008, at 8:19
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
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
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
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
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
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
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
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
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
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
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
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
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
Hello,
I have the following code :
if (![fileMgr fileExistsAtPath: indexFilePath]) {
NSMutableDictionary *index = [[NSMutableDictionary alloc] init];
[index setObject: [NSNumber numberWithLong: DEFAULTS_BLOCKSIZE]
forKey: INDEXKEY_BLOCKSIZE];
[index setObject:
If you use convenience methods (as in the else branch) it is autoreleased.
See here for details:
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concepts/ObjectOwnership.html#//apple_ref/doc/uid/2043
On Thu, Mar 13, 2008 at 8:19 AM, Daniel Luis dos Santos
[EMAIL
On Mar 13, 2008, at 9:19 AM, Daniel Luis dos Santos wrote:
NSDictionary *index = [NSDictionary dictionaryWithContentsOfFile:
indexFilePath];
This dictionary is autoreleased when it's given to you, hence the
error when you try to release it. Refer to
81 matches
Mail list logo
