Re: Releasing Objects
On Wed, Dec 23, 2009 at 12:05 PM, Bill Bumgarner b...@mac.com wrote:
On Dec 22, 2009, at 11:49 PM, Franck Zoccolo wrote:
You said that you're using garbage collection. When using GC retain and
release messages do nothing, and the retain count is not used to
determine when an objet can be freed from memory.
If -retainCount is returning 1, then he can't be using GC. Under GC,
-retainCount -- being the utterly useless method that it is that no one
should ever call -- returns self.
b.bum
Wait, what? I could understand that under GC -retain might be nothing more
than the equivalent of - (id)retain { return(self); }, but -retainCount?
Is it really - (NSUInteger)retainCount { return((NSUInteger)self); } ?
Wouldn't it make more sense to just return 1, or maybe something like
NSUIntegerMax?
___
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 arch...@mail-archive.com
Re: Releasing Objects
On Dec 24, 2009, at 2:23 AM, John Engelhart wrote:
On Wed, Dec 23, 2009 at 12:05 PM, Bill Bumgarner b...@mac.com wrote:
On Dec 22, 2009, at 11:49 PM, Franck Zoccolo wrote:
You said that you're using garbage collection. When using GC retain and
release messages do nothing, and the retain count is not used to
determine when an objet can be freed from memory.
If -retainCount is returning 1, then he can't be using GC. Under GC,
-retainCount -- being the utterly useless method that it is that no one
should ever call -- returns self.
b.bum
Wait, what? I could understand that under GC -retain might be nothing more
than the equivalent of - (id)retain { return(self); }, but -retainCount?
Is it really - (NSUInteger)retainCount { return((NSUInteger)self); } ?
Wouldn't it make more sense to just return 1, or maybe something like
NSUIntegerMax?
There is no implementation of -retainCount under GC. There's a short-circuit
in obj_msgSend that detects the selector for the memory management methods
which are no-ops. Since -retain and -autorelease have to return self, that's
what the short-circuit does. -retainCount gets the same treatment and so the
same return value. The return value doesn't matter, anyway. (Frankly, it
hardly matters under managed memory, either.)
Regards,
Ken
___
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 arch...@mail-archive.com
Re: Releasing Objects
On Dec 24, 2009, at 12:47 AM, Ken Thomases wrote:
On Dec 24, 2009, at 2:23 AM, John Engelhart wrote:
Wait, what? I could understand that under GC -retain might be nothing more
than the equivalent of - (id)retain { return(self); }, but -retainCount?
Is it really - (NSUInteger)retainCount { return((NSUInteger)self); } ?
Wouldn't it make more sense to just return 1, or maybe something like
NSUIntegerMax?
There is no implementation of -retainCount under GC. There's a short-circuit
in obj_msgSend that detects the selector for the memory management methods
which are no-ops. Since -retain and -autorelease have to return self, that's
what the short-circuit does. -retainCount gets the same treatment and so the
same return value. The return value doesn't matter, anyway. (Frankly, it
hardly matters under managed memory, either.)
More precisely, there's exactly one short-circuit check and thus only one
selector value. Under GC, @selector(retain) == @selector(release) ==
@selector(autorelease) == @selector(dealloc) == @selector(retainCount).
Happily, `return self` works to implement all of those.
Don't write any code that relies on those selectors being equal, though. It
will change in the future.
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
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 arch...@mail-archive.com
Re: Releasing Objects
On Thu, Dec 24, 2009 at 5:13 PM, Greg Parker gpar...@apple.com wrote: More precisely, there's exactly one short-circuit check and thus only one selector value. Under GC, @selector(retain) == @selector(release) == @selector(autorelease) == @selector(dealloc) == @selector(retainCount). Happily, `return self` works to implement all of those. Just out of curiosity, is that really a short-circuit in the message-passing machinery, or are all those selectors simply registered to point to the same IMP function? A useless bit of knowledge for us end-users, I know, but interesting just the same. Greg Parker gpar...@apple.com Runtime Wrangler I think that should be Wruntime Wrangler. :-) sherm-- -- Cocoa programming in Perl: http://www.camelbones.org ___ 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 arch...@mail-archive.com
Re: Releasing Objects
On 24 dec 2009, at 15.16, Sherm Pendley wrote: Just out of curiosity, is that really a short-circuit in the message-passing machinery, or are all those selectors simply registered to point to the same IMP function? A useless bit of knowledge for us end-users, I know, but interesting just the same. Short circuited. See: http://www.friday.com/bbum/2009/12/18/objc_msgsend-tour-part-3-the-fast-path/ 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 arch...@mail-archive.com
Re: Releasing Objects
On Thu, Dec 24, 2009 at 7:36 PM, Joar Wingfors j...@joar.com wrote: On 24 dec 2009, at 15.16, Sherm Pendley wrote: Just out of curiosity, is that really a short-circuit in the message-passing machinery, or are all those selectors simply registered to point to the same IMP function? A useless bit of knowledge for us end-users, I know, but interesting just the same. Short circuited. See: http://www.friday.com/bbum/2009/12/18/objc_msgsend-tour-part-3-the-fast-path/ Wow, that's a *fascinating* read! Thanks! sherm-- -- Cocoa programming in Perl: http://www.camelbones.org ___ 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 arch...@mail-archive.com
Re: Releasing Objects
On Dec 24, 2009, at 3:16 PM, Sherm Pendley wrote: On Thu, Dec 24, 2009 at 5:13 PM, Greg Parker gpar...@apple.com wrote: More precisely, there's exactly one short-circuit check and thus only one selector value. Under GC, @selector(retain) == @selector(release) == @selector(autorelease) == @selector(dealloc) == @selector(retainCount). Happily, `return self` works to implement all of those. Just out of curiosity, is that really a short-circuit in the message-passing machinery, or are all those selectors simply registered to point to the same IMP function? A useless bit of knowledge for us end-users, I know, but interesting just the same. Both. There are an extra two instructions at the start of most flavors of objc_msgSend(). That's intended to do nothing fast. The method lookup machinery also recognizes that selector value, and hands back a `return self` IMP. That's for the benefit of code that looks up IMPs and calls them directly. The second half was missing at one point during Leopard development. Some code was looking up IMPs for -retain and -release. But under GC the methods named above share the same selector value, so the runtime handed back the first method in the class's method list with that selector. For most classes this is the -dealloc implementation. Hilarity ensued. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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 arch...@mail-archive.com
Re: Releasing Objects
On Dec 22, 2009, at 11:49 PM, Franck Zoccolo wrote: You said that you're using garbage collection. When using GC retain and release messages do nothing, and the retain count is not used to determine when an objet can be freed from memory. If -retainCount is returning 1, then he can't be using GC. Under GC, -retainCount -- being the utterly useless method that it is that no one should ever call -- returns self. b.bum ___ 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 arch...@mail-archive.com
Re: Releasing Objects
On Dec 22, 2009, at 9:40 pm, Michael Craig wrote: At the point where the tutorial discusses garbage collection (end of ch. 5), I decided to implement the deallocation of the Converter objects created by ConverterController's convert: method. I want the deallocation to happen inside convert:. To test it, I'm using [converter retainCount], thinking that after the object is deallocated, that call will cause an error. This is the wrong way to think about memory management. You shouldn't be thinking in terms of deallocating another object, only in terms of ownership. You want to relinquish ownership of an object when you've finished with it. This is discussed in greater detail in http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmObjectOwnership.html#//apple_ref/doc/uid/2043 and the memory management rules summarised in http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html#//apple_ref/doc/uid/2994. To elaborate on bbum's messages, the documentation for retainCount is quite explicit... http://developer.apple.com/mac/library/documentation/Cocoa/Reference/Foundation/Protocols/NSObject_Protocol/Reference/NSObject.html#//apple_ref/occ/intfm/NSObject/retainCount 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 arch...@mail-archive.com
Re: Releasing Objects
Michael Craig wrote: If I'm missing some key concept here, just point me in the right direction and I'll go learn it. If it's something more specific, fill me in! In ownership terms, you released the object, so you no longer own it. References to it after that point are illegal, even if the object still exists because it's owned elsewhere. In allocation terms, the instant an object is deallocated, it is no longer a valid object. This does not mean that every reference to it, via its id, will now cause a runtime error. There are practical reasons for doing this, even though it may deviate from a desirable ideal. On the practical level, the memory reclaimed from a deallocated object is not zeroed, filled, marked, or otherwise altered, except as needed by the free-space management code. Freed memory may be reused as other objects are created, so any dangling id from the dead object is no longer an id, but a dangling C pointer: a dangerous thing with unspecified behavior. Your first premise was that an object's retain-count goes to zero, then it's deallocated. In short, you assume there is a brief interval when a valid object has a retain-count of zero, right before it winks out of existence as an object. Logically, however, this is unnecessary. With a retain-count of 1, the release code knows with certainty that the object's memory will be freed, so writing anything to that memory, such as 0 to the retain-count, is unnecessary. If something is unnecessary and executed frequently, it should be eliminated. Your other premise was that a deallocated object will instantly trigger runtime errors when further messaged. That may be an ideal, but it's definitely not how the real runtime works. Better still, what if it's impossible to even have a reference to an invalid object: if you have an id, it exists. That's what GC tries to provide, though it still isn't ideal. -- GG ___ 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 arch...@mail-archive.com
Re: Releasing Objects
Thanks! I've got a better grip on memory management now. By the way, I'm working with GC turned off, for the sake of learning this stuff. My bad for not including that. Michael S Craig ___ 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/mkscrg%40gmail.com This email sent to mks...@gmail.com ___ 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 arch...@mail-archive.com
Releasing Objects
Hi folks,
I'm new to Cocoa but I think I have a passable understanding of Obj-C.
I'm learning Cocoa for a part of an undergraduate comp-sci independent
project.
I'm working through the Cocoa Application Tutorial, found here:
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjCTutorial/01Introduction/01Introduction.html
At the point where the tutorial discusses garbage collection (end of ch. 5),
I decided to implement the deallocation of the Converter objects created by
ConverterController's convert: method. I want the deallocation to happen
inside convert:. To test it, I'm using [converter retainCount], thinking
that after the object is deallocated, that call will cause an error.
First I tried [converter release], which didn't work. My code for convert:
looks like this:
-(IBAction) convert: (id) sender {
float amount;
converter = [[Converter alloc] init];
[converter setSourceCurrencyAmount: [dollarField floatValue]];
[converter setRate: [rateField floatValue]];
amount = [converter convertCurrency];
[rateField selectText: self]; // autorelease ineff. if b4 this
line. hmmm.
[amountField setFloatValue: amount];
NSLog(@Reference count: %lx, (unsigned long) [converter retainCount]);
[converter release];
NSLog(@Reference count: %lx, (unsigned long) [converter retainCount]);
}
Everything else is the same as is given in the tutorial. The console shows
that the reference count of converter is 1 both before and after the
release. Why?
Next I tried using an autorelease pool inside the convert method. My code
for convert: looks like this:
-(IBAction) convert: (id) sender {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
float amount;
converter = [[Converter alloc] init];
[converter setSourceCurrencyAmount: [dollarField floatValue]];
[converter setRate: [rateField floatValue]];
amount = [converter convertCurrency];
[amountField setFloatValue: amount];
[rateField selectText: self];
[converter autorelease];
NSLog(@Reference count: %lx, (unsigned long) [converter retainCount]);
[pool drain];
NSLog(@Reference count: %lx, (unsigned long) [converter retainCount]);
}
Once again, everything else is the same. Now it works: and the console shows
that the ref count is 1 before the pool drain and then there's an error
(EXC_BAD_ACCESS). HOWEVER: If the [converter autorelease] call is moved up
so it happens anywhere prior to the [rateField selectText: self] call, it
doesn't work. The console now shows a ref count of 1 both before and after
the pool drain. Once again, why?
If I'm missing some key concept here, just point me in the right direction
and I'll go learn it. If it's something more specific, fill me in!
Thanks,
Michael S Craig
___
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 arch...@mail-archive.com
Re: Releasing Objects
On Dec 22, 2009, at 9:40 PM, Michael Craig wrote: NSLog(@Reference count: %lx, (unsigned long) [converter retainCount]); [converter release]; NSLog(@Reference count: %lx, (unsigned long) [converter retainCount]); If the -release is going to deallocate converter, then the subsequent -retainCount's behavior is undefined. b.bum ___ 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 arch...@mail-archive.com
Re: Releasing Objects
On 23/12/2009 06:40, Michael Craig wrote: Everything else is the same as is given in the tutorial. The console shows that the reference count of converter is 1 both before and after the release. Why ? You said that you're using garbage collection. When using GC retain and release messages do nothing, and the retain count is not used to determine when an objet can be freed from memory. ___ 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 arch...@mail-archive.com
Releasing objects in Scripting Bridge
Exploring the example of sending emails using Scripting Bridge, I see that objects are allocated but not released: MailOutgoingMessage *emailMessage = [[[mail classForScriptingClass:@outgoing message] alloc] initWithProperties: [NSDictionary dictionaryWithObjectsAndKeys:@testing sending mail, @subject,messageString, @content, nil]]; this is where the object is created with an alloc, but it is not released later. This also occurs in other parts of the code. Is this a mistake or is this not necessary when calling through to the scripts to other applications. Thanks again Reza ___ 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 arch...@mail-archive.com
confused about allocating and releasing objects
HI All, i'm a bit confused about the 2 scenarios: NSDictionary *myData1 = [NSDictionary dictionaryWithContentsOfFile:@mydata.plist]; // this one I don't need to release when I'm done? NSDictionary *myData2 = [[NSDictionary alloc] initWithContentsOfFile:@mydata.plist]; // this one I do need to relase when I'm done? There seems to be a lot of situations in Cocoa where this happens so I guess this is a generic question for all cases when an object is created via means of a static method vs using alloc:initWith... (e.g. NSArray, NSString, NSNumber etc. are just a few I've seen). Whats the difference between the two methods? (I know the second one creates a blank dictionary first, and then loads the file - but I mean which one is better for what purpose? - why would I choose one over the other). And am I correct in assuming if I use the first method i do not need to release the variable when I'm done? but do need to release the variable in the second instance? Cheers, Memo. ___ 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: confused about allocating and releasing objects
On Wed, Aug 27, 2008 at 11:45 AM, Memo Akten [EMAIL PROTECTED] wrote: HI All, i'm a bit confused about the 2 scenarios: NSDictionary *myData1 = [NSDictionary dictionaryWithContentsOfFile:@mydata.plist]; // this one I don't need to release when I'm done? NSDictionary *myData2 = [[NSDictionary alloc] initWithContentsOfFile:@mydata.plist];// this one I do need to relase when I'm done? There seems to be a lot of situations in Cocoa where this happens so I guess this is a generic question for all cases when an object is created via means of a static method vs using alloc:initWith... (e.g. NSArray, NSString, NSNumber etc. are just a few I've seen). Whats the difference between the two methods? (I know the second one creates a blank dictionary first, and then loads the file - but I mean which one is better for what purpose? - why would I choose one over the other). Use whichever is easiest. Generally if I'm looking for a temporary object, I'll use the autoreleased method if present. If I'm going to keep the object around, I'll use the alloc/init method. But either of these can be transformed to the other with a retain or autorelease message, so there's no huge difference. And am I correct in assuming if I use the first method i do not need to release the variable when I'm done? but do need to release the variable in the second instance? Correct. Review http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.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: confused about allocating and releasing objects
ok thanks, Ive added that link to my ever growing Cocoa bookmarks!!
I'm just writing a Quartz Composer plugin using the QCPlugIn API and
ran into a problem regarding this, my question isn't related to the
QCPlugIn API so I'm posting here first.
At the start of the plugin (in enableExecution) I use the code:
- (void) loadCardXMLData {
NSString *dataPath = @/data.plist;
cardsLoadedData = [NSDictionary dictionaryWithContentsOfFile:
dataPath];
// cardsLoadedData = [[NSDictionary alloc] initWithContentsOfFile:
dataPath];
if(cardsLoadedData) {
NSLog(@*** SUCCESSFULLY LOADED %@, dataPath);
} else {
NSLog(@*** COULD NOT LOAD %@, dataPath);
}
}
If I use the convenience route (with no release in disableExecution) I
get a freeze (I need to force quit QC) as soon as I enable the plugin.
If I use the alloc route (and release in disableExecution) everything
works fine. Is this normal behaviour? or could it be QC related?
P.S. cardsLoadedData is a property of my QCPlugIn class, and I don't
use it at all except at the end of execute I just send it out to QC
with self.outputXMLData = cardsLoadedData;
Cheers,
Memo.
On 27 Aug 2008, at 11:57, Jonathan del Strother wrote:
On Wed, Aug 27, 2008 at 11:45 AM, Memo Akten [EMAIL PROTECTED] wrote:
HI All, i'm a bit confused about the 2 scenarios:
NSDictionary *myData1 = [NSDictionary
dictionaryWithContentsOfFile:@mydata.plist]; // this one
I don't
need to release when I'm done?
NSDictionary *myData2 = [[NSDictionary alloc]
initWithContentsOfFile:@mydata.plist];// this one
I do
need to relase when I'm done?
There seems to be a lot of situations in Cocoa where this happens
so I guess
this is a generic question for all cases when an object is created
via means
of a static method vs using alloc:initWith... (e.g. NSArray,
NSString,
NSNumber etc. are just a few I've seen).
Whats the difference between the two methods? (I know the second
one creates
a blank dictionary first, and then loads the file - but I mean
which one is
better for what purpose? - why would I choose one over the other).
Use whichever is easiest. Generally if I'm looking for a temporary
object, I'll use the autoreleased method if present. If I'm going to
keep the object around, I'll use the alloc/init method. But either of
these can be transformed to the other with a retain or autorelease
message, so there's no huge difference.
And am I
correct in assuming if I use the first method i do not need to
release the
variable when I'm done? but do need to release the variable in the
second
instance?
Correct. Review
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.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/memo%40memo.tv
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: confused about allocating and releasing objects
On 27 Aug 2008, at 9:13 pm, Memo Akten wrote:
At the start of the plugin (in enableExecution) I use the code:
- (void) loadCardXMLData {
NSString *dataPath = @/data.plist;
cardsLoadedData = [NSDictionary dictionaryWithContentsOfFile:
dataPath];
// cardsLoadedData = [[NSDictionary alloc] initWithContentsOfFile:
dataPath];
if(cardsLoadedData) {
NSLog(@*** SUCCESSFULLY LOADED %@, dataPath);
} else {
NSLog(@*** COULD NOT LOAD %@, dataPath);
}
}
If I use the convenience route (with no release in disableExecution)
I get a freeze (I need to force quit QC) as soon as I enable the
plugin. If I use the alloc route (and release in disableExecution)
everything works fine. Is this normal behaviour? or could it be QC
related?
Just thinking aloud, but I wonder if the plug-in is being executed
outside of the app's autorelease pool stack? The freeze could be
because autorelease is being called but there's no pool available. You
could try adding a pool to the top of the code to see if it stabilises
it, e.g. on the first line of the above:
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
If that turns out to be the case, you may need to move your code
elsewhere within the plugin (I'm not familiar with the plug-in system
in Cocoa so I'm not sure what you should be doing here) or else set up
a pool on entry.
hth,
Graham
___
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: confused about allocating and releasing objects
On Wed, Aug 27, 2008 at 12:13 PM, Memo Akten [EMAIL PROTECTED] wrote:
ok thanks, Ive added that link to my ever growing Cocoa bookmarks!!
I'm just writing a Quartz Composer plugin using the QCPlugIn API and ran
into a problem regarding this, my question isn't related to the QCPlugIn API
so I'm posting here first.
At the start of the plugin (in enableExecution) I use the code:
- (void) loadCardXMLData {
NSString *dataPath = @/data.plist;
cardsLoadedData = [NSDictionary dictionaryWithContentsOfFile: dataPath];
// cardsLoadedData = [[NSDictionary alloc] initWithContentsOfFile:
dataPath];
if(cardsLoadedData) {
NSLog(@*** SUCCESSFULLY LOADED %@, dataPath);
} else {
NSLog(@*** COULD NOT LOAD %@, dataPath);
}
}
If I use the convenience route (with no release in disableExecution) I get a
freeze (I need to force quit QC) as soon as I enable the plugin. If I use
the alloc route (and release in disableExecution) everything works fine. Is
this normal behaviour? or could it be QC related?
P.S. cardsLoadedData is a property of my QCPlugIn class, and I don't use it
at all except at the end of execute I just send it out to QC
with self.outputXMLData = cardsLoadedData;
Cheers,
Memo.
You're assigning an autoreleased object to your cardsLoadedData ivar.
Next time the autorelease pool pops, your dictionary is going to get
released. Either retain the dictionary, or use alloc+init, or
(preferably) use self.cardsLoadedData= instead of just
cardsLoadedData=, which will assign via the property method, which
will retain for you (assuming you've set up the property correctly).
___
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: confused about allocating and releasing objects
If you had access to the NSDictionary source code you'd find that the
NSDictionary's +dictionaryWithContentsOfFile:(NSString*)fileName would
probably look something like this:
+(NSDictionary*) dictionaryWithContentsOfFile:(NSString*)fileName
{
return [[[NSDictionary alloc] initWithContentsOfFile] autorelease];
}
As you can see it's not really doing anything all that special. It's
really just saving you some typing and having to release it yourself if
it's for a temporary variable.
Devon
Memo Akten wrote:
HI All, i'm a bit confused about the 2 scenarios:
NSDictionary *myData1 = [NSDictionary
dictionaryWithContentsOfFile:@mydata.plist];// this one I
don't need to release when I'm done?
NSDictionary *myData2 = [[NSDictionary alloc]
initWithContentsOfFile:@mydata.plist];// this one I do need to
relase when I'm done?
There seems to be a lot of situations in Cocoa where this happens so I
guess this is a generic question for all cases when an object is created
via means of a static method vs using alloc:initWith... (e.g. NSArray,
NSString, NSNumber etc. are just a few I've seen).
Whats the difference between the two methods? (I know the second one
creates a blank dictionary first, and then loads the file - but I mean
which one is better for what purpose? - why would I choose one over the
other). And am I correct in assuming if I use the first method i do not
need to release the variable when I'm done? but do need to release the
variable in the second instance?
Cheers,
Memo.
___
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: confused about allocating and releasing objects
On Wed, Aug 27, 2008 at 7:22 AM, Graham Cox [EMAIL PROTECTED] wrote: Just thinking aloud, but I wonder if the plug-in is being executed outside of the app's autorelease pool stack? The freeze could be because autorelease is being called but there's no pool available. In general, that doesn't freeze an app. It just emits a warning to the console that says autorelease was called without a pool in place, and that the autoreleased object will be leaked as a result. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net ___ 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]
Releasing objects causes BAD_ACCESS
Dear all, according to the document http://developer.apple.com/documentation/Cocoa/Conceptual/URLLoadingSystem/Tasks/UsingNSURLConnection.html the connection object as well as the receivedData object are released in the connectionDidFinishLoading delegate. However, while debugging, I receive an BAD_ACCESS violation doing the release. Can anyone please give me some insight on why this is happening? Is there any strategy/ debugging tool that helps me to find objects that should have been released or should I just rely on GC? Thanks so much Best regards Meik ___ 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: Releasing objects causes BAD_ACCESS
On Mon, Jul 7, 2008 at 10:38 PM, Meik Schuetz [EMAIL PROTECTED] wrote: Dear all, according to the document http://developer.apple.com/documentation/Cocoa/Conceptual/URLLoadingSystem/Tasks/UsingNSURLConnection.html the connection object as well as the receivedData object are released in the connectionDidFinishLoading delegate. However, while debugging, I receive an BAD_ACCESS violation doing the release. Can anyone please give me some insight on why this is happening? Is there any strategy/ debugging tool that helps me to find objects that should have been released or should I just rely on GC? NSZombieEnabled is a good start - http://developer.apple.com/technotes/tn2004/tn2124.html#SECFOUNDATION ___ 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: Releasing objects causes BAD_ACCESS
On Jul 7, 2008, at 3:44 PM, Jonathan del Strother wrote: On Mon, Jul 7, 2008 at 10:38 PM, Meik Schuetz [EMAIL PROTECTED] wrote: according to the document http://developer.apple.com/documentation/Cocoa/Conceptual/URLLoadingSystem/Tasks/UsingNSURLConnection.html the connection object as well as the receivedData object are released in the connectionDidFinishLoading delegate. However, while debugging, I receive an BAD_ACCESS violation doing the release. Can anyone please give me some insight on why this is happening? Is there any strategy/ debugging tool that helps me to find objects that should have been released or should I just rely on GC? NSZombieEnabled is a good start - http://developer.apple.com/technotes/tn2004/tn2124.html#SECFOUNDATION See also Technical Note TN2124 - Mac OS X Debugging Magic: http://developer.apple.com/technotes/tn2004/tn2124.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: Releasing objects causes BAD_ACCESS
the connection object as well as the receivedData object are released in the connectionDidFinishLoading delegate The sample also retains receivedData after creating the connection. Did you do that? And did you create the connection using alloc initxxx? -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.com/ (303) 722-0567 voice ___ 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]
