I changed my mind, when I was writting this
- (void)sendSharedMessage:(NSString *)msg
{
NSString *print = [[[NSString alloc] initWithFormat:@" %@",msg] autorelease];
NSLog(@" %@", print);
}
anyway it doesn't change the background
On Sun, Mar 22, 2009 at 2:47 PM, mm w <openspec...@gmail.com> wrote:
> Hello David,
>
> your garbage collection approach is a bit naive, but not everything
> is wrong, you can make a google search, it will point you good
> resources anyway,
>
> @implementation AppDelegate
>
> - (void)sendSharedMessage:(NSString *)msg
> {
> return [[[NSString alloc] initWithFormat:@" %@",msg] autorelease];
> }
>
> @end
>
>
> @implementation MyObject
>
> - (void)aMathod
> {
> id sharedController = [[NSApplication sharedApplication] delegate];
>
> if ([[sharedController class]
> instancesRespondToSelector:@selector(sendSharedMessage:)]) {
> NSString aMsg = [[NSString alloc] initWithString:@"hello"];
> [sharedController performSelector:@selector(sendSharedMessage:)
> withObject:aMsg];
> [aMsg release];
> }
>
> }
>
> @end
>
> (sorry if there is synthax errors this is a live code)
>
> this model will apply with/or without garbage collection, release
> autorelease will be ignored in garbage collection env, avoid "as far
> is possible" circular refs by a proper design.
>
> On Sat, Mar 21, 2009 at 9:16 PM, Bill Bumgarner <b...@mac.com> wrote:
>> On Mar 21, 2009, at 9:11 PM, David wrote:
>>>
>>> Is there any issue issuing explicit release when using garbage
>>> collection with Leopard and Obj-c 2.0?
>>
>> -release is ignored entirely.
>>
>> CFRelease() work as it always does, and balances CFRetain() nicely.
>>
>> But that isn't the issue.
>>
>>> I've become aware that I have lots of memory not being freed within my
>>> application. I presume this is because its a tree structure with
>>> parent child pointers between the objects. If I drop the last
>>> reference to the tree, I presume the tree does not get garbage
>>> collected because each object has circular pointers between them, ie
>>> parent has references to children and each child has a reference to
>>> its parent. In this case, it seem that the appropriate course of
>>> action would be to call a specific method to forcibly release each
>>> node in the tree.
>>> Is this the proper approach?
>>> Should garbage collection somehow work anyway?
>>
>> That would be an incorrect presumption. The garbage collector handles
>> complexly connected, but not rooted, graphs just fine. Your sub-graphs --
>> trees -- of objects that are no longer referenced by your rooted object
>> graphs should be reaped without a problem.
>>
>> So, something else is going on.
>>
>> Have you used 'info gc-roots' to see what is causing the items within your
>> tree to stick around?
>>
>> 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/openspecies%40gmail.com
>>
>> This email sent to openspec...@gmail.com
>>
>
>
>
> --
> -mmw
>
--
-mmw
_______________________________________________
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
