Re: garbage collection and NSConnection
Re: garbage collection and NSConnection
- Subject: Re: garbage collection and NSConnection
- From: "Joan Lluch (casa)" <email@hidden>
- Date: Thu, 3 Jul 2008 00:09:13 +0200
El 30/06/2008, a las 19:33, email@hidden escribió:
hey,
I have a project that uses Bonjour for some of its communication,
theres a server and a client, and I was having tremendous difficulty
getting it to work, pouring and pouring over my code, only to
discover some weeks later that for some odd reason, NSConnections do
not work when the project is set to support or require garbage
collection.
As a test I set garbage collection to: Unsupported, and the app
compiled, and the NSConnection returned the proxy object as
expected. But the app obviously failed to do much else, because I
had no retain, release, or autorelease method calls.
I am not a lazy person, but I am a novice programmer, and the
retain, release, autorelease stuff in cocoa is horrible. I was very
happy when garbage collection was added to Cocoa, and my projects
became much easier to develop, and maintain. Now however, I find
myself with a project riddled with memory problems that did Not
exist just a few days ago, and as far as I can tell, I don't have
any choice... My app either gives up Bonjour, or I have to retrofit
the whole thing to manage its own memory with a system that is, lets
face it, poorly envisioned.
can anybody shed any light on this? am I really stuck managing the
memory myself? This is intolerable.
cheers,
-eblu
_______________________________________________
Well, it always takes a risk to embrace a technology that is just
released, such as garbage collection. Cocoa APIs and the Objective-C
language was not designed from its origins with garbage collection in
mind, so it must have been a really tedious and bug prone process for
Apple to convert all the frameworks to properly work in a managed
memory context. This is unlike Java and C#, which have been created
from the beginning with such feature. In any case, Garbage collection
is neither good or bad, it certainly allows you to not have to care
about Zombies and Leaks, but you will still have to think about the
lifetime of objects. You will still have to remove observers, or
unbind objects, and think that your objects will be eventually
reclaimed by the garbage collector, in an undefined order, so you will
have to implement finalize methods.
From my experience, at the end of the day, coding in a garbage
collected environment, is not such a better deal. Obj-C, unlike C++,
has a very clean way to deal with memory: the release/autorelease/
retain way to manage your memory, along with autorelease pools, and
the consistence of the Cocoa APIs with respect to returned objects,
are heaven compared to what you have to implement in C++, or other not
managed memory languages.
Basically, all you have to do is to always return autoreleased objects
from your methods, and always send release to objects that you created
with alloc or were returned by any method containing "new" or "copy".
Also, if you only use the standard accessor methods for setting
properties, (which send release to the old object and retain the new
one), you will not incur in any memory problem. It should not be that
hard, and at the end your application will potentially perform better,
and for sure it will eat significantly less memory.
Joan Lluch.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden