Re: Debugging retainCount
Re: Debugging retainCount
- Subject: Re: Debugging retainCount
- From: publiclook <email@hidden>
- Date: Tue, 15 Jul 2003 22:38:55 -0400
On Tuesday, July 15, 2003, at 09:34 PM, Stefan Pantke wrote:
Beginning cocoa some time ago, I disliked this sentence as well.
Compared with
Java's rules (simply forget deallocating, Java does) or C's rules
(allways deallocate,
if you allocated), Obj-C is in fact a bit more complicated.
If you have ever written non-trivial C code, you are probably aware
that malloc() and free() are notoriously difficult to use in many
situations. The question of when and how to free resources returned
from a function is ever-present. That is why many libraries resort to
special allocators, impose conventions, use opaque types and handles,
and GASP use reference counting. For example, Microsofts COM and DCOM
are C APIs that require the use of reference counting.
You may also share my impression that the number one most common
complaint about Java is the garbage collector and the lack of control,
performance hits, non-determinism, random impact on latency of
operations, and sloppiness encouraged by the garbage collector. It is
disgusting how many thousands or millions of temporary objects are
created per second within Swing when almost all could be avoided.
However, variety is the spice of life, and Java has many nice features
that I like.
I think, this rule applies:
- If you use a convenience function
Forget on deallocating, runtime does it
- If using allocation with incremented retain count (explicitly by
retain or implicitly)
Release it
I think it is better stated as the following:
"Within a given block, every use of -copy*, -alloc* and -retain should
be paired with the use of -release or -autorelease."
The rule even applies to accessor methods.
There aren't special cases.
If you didn't call a method that includes the words alloc, copy, or
retain the don't worry about it. Why is that hard ?
IMHO, strict requirements are generally speaking, a good feature.
Strict requirements
often result in errors found earlier in development processes.
Although I hate getting error messages from the runtime system, I love
to
get error messages (find errors) before I release software ;-)
Am Mittwoch, 16.07.03 um 02:32 Uhr schrieb David P Henderson:
Seriously, how hard is it to understand "... only send release or
autorelease to an object to which you have explicitly sent one of the
following messages: alloc, copy or retain." In other words, if you
did not allocate, copy or retain the object; then, do not try to
release it. IMHO, most of these problems stem from people over
thinking this whole process or poor design.
Dave
--
Chaos Assembly Werks
"The proper office of a friend is to side with you when you are in
the wrong. Nearly anybody will side with you when you are in the
right."
- Mark Twain
--
Chaos Assembly Werks
"Imagination is more important than knowledge."
- Albert Einstein
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.