RE: Memory management question (passing objects to method)
RE: Memory management question (passing objects to method)
- Subject: RE: Memory management question (passing objects to method)
- From: Jeff Laing <email@hidden>
- Date: Thu, 3 Mar 2005 16:16:47 +1100
> We aren't returning values from these things, we are talking about
> memory management (retain/release/init/dealloc).
Well, in this specific case, the example code relied on the return value
from retain. So it seems to me that it was relevant.
> So by your theory beginners should do memory management throughout
> their class, while the rest of us keep the memory management of our
> instance vars contained within our accessors?
No, not at all. Personally, I think beginners should be doing
if (aString != value) {
[value release];
value = aString;
if (value) [value retain];
}
and that, in my *personal* opinion, is clearer to the reader that there will
be cases where aString will be nil. Thats putting aside the optimisation
issue ( I'll bet my left ball that short-circuiting the retain call if
value=nil will be way faster at runtime than letting objc_msgSend() do its
thing, and I want all my accessor functions to be as fast as possible. Yes,
thats arguing about microseconds. No, I haven't considered the impact of
threading)
Remember, this is a thread that contained the rather misguided advice that
[ptr autorelease];
ptr = nil;
would somehow cause a problem because the autorelease pool would get
confused by the variable 'ptr' having been set to nil. I think you
overestimate exactly how little beginners really know.
> Much of what makes a good objective-c programmer is about subtlety. The
> more obvious way is not always the best, and with something like memory
> management, it's best to teach good practice whilst at the same time
> pointing out those subtleties.
Which would be fine if the subtlety here had been pointed out. It wasn't.
Even having had:
if (aString != value) {
[value release];
value = [aString retain]; // note: value = nil if
aString = nil
}
would have improved the sample, for the beginner, who is known to be goofing
up his retain/release calls! I had to look twice to see why it worked for
the case of aString == nil, and that required explicit knowledge of the
non-intuitive subtlety that ([nil retain] == nil), which I doubt highly that
all beginners have truly taken on board, especially those that don't
understand that ptr=nil; does not affect *ptr one iota.
(Ok, there are the poor souls who've come over from C++ / Java land that
think nulling ptr may well free the object because its last reference has
disappeared - again, this is compatible with a lack of understanding of when
to balance release/retain calls)
Personally, what I find appalling is the lack of COMMENT is just about all
open-source software thats out there. It used to be that you could learn by
reading other peoples samples. Nowadays, with more of the application
living out in bindings, and nibs, and everyone believing that their code is
"self-documenting", its becoming bloody difficult to see the forest OR the
trees.
And yes, I know, it wasn't production code, it was just typed into an email
so putting comments in it would have been extra effort, as has been me
ranting about it. My only hope is that people will understand that, when
responding to people asking these sort of basic questions on a mailing list,
very few of them are ready for the super-optimised solutions, and they may
learn as many bad habits as good.
> A clear example of where the use of your accessors in your dealloc
> ensures consistency is when you have instance vars which aren't
> retained.
I didn't say "don't use accessors in dealloc". By all means do that, its
clearly the right way to go since it correctly bottlenecks your
retain/release calls.
What I said was that the accessor as presented still contained subtle
ambiguities that most beginners would miss.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden