Because I am like this I won't do the job for you, I will only point
you directions, that's it
Google "garbage collection", it's naive to think that's a "linear" tree.
What Bill told you is right, and my comment is following his thought
Avoiding circular refs: in 95% of cases it can be avoided, by
refactoring his work,
taking a pen and a white paper... and think
Cheers!
On Sun, Mar 22, 2009 at 3:21 PM, David Melgar <enki1...@gmail.com> wrote:
> I'm confused. Bill said that the garbage collection will correctly handle
> releasing these types of objects despite the circular references. Therefore
> it appears that no additional actions are required since I am using garbage
> collection.
>
> What is your approach trying to solve?
> I certainly don't follow your reply. Google for what?
> Naive in what way?
> Avoid circular refs by a "proper" design? Ok... what is "proper"?
>
> Generally your message alludes to many things yet provides little
> information.
>
> On Mar 22, 2009, at 5:53 PM, mm w wrote:
>
>> 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
>
>
--
-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
