On Sep 7, 2009, at 2:32 AM, John Engelhart wrote:
To my recollection, I have never discussed this problem on the
list. I have
discussed the following:
The list of things you've discussed already sounds effectively
identical to the point you brought up.
Your question "Does the Mac OS X garbage collector support interior
pointers?" seems completely rhetorical, as you already know the answer
(no) and, as you say, have discussed the issue here before. So I don't
see what the point of your post was, other than to pick a fight.
A) The compiler is generating code that violates the C standard.
B) Because of this, it significantly complicates writing code that
uses
garbage collection.
I understand your reasoning with point A, but I don't think it's
valid. The C spec cannot cover platform-specific special-purpose
allocators, only the ones in the standard. GC does not change the
behavior of auto or malloc'ed blocks. The fact that there is a OS X-
specific library function that will return pointers to memory that can
be freed even when interior pointers to it exist, has nothing to do
with the C spec.
Point B is something that can only be answered anecdotally, and in my
experience of GC-based Obj-C development, I've never run into this
issue. I'm not concerned about obscure corners of the C standard that
don't affect the way I code. Sure, if I allocate an object, then keep
a pointer that points into the middle of the object, while not keeping
any references to the object itself, the object will be collected and
my pointer will be bad. But why on earth would I write code like that?
It's code that, in the absence of GC, would leak memory (because I
forget about the allocated object pointer.) I could recover the object
pointer by doing some arithmetic backwards from the interior pointer,
but that's pretty skanky — I'd only be doing that level of stuff if I
were doing something like writing my own memory manager, which I of
course would not be doing inside an Objective-C object.
John, you are aware that Obj-C garbage collection is optional and opt-
in, right? If you don't like its semantics, don't use it. If you still
feel a strong need to expose to the world how flawed it is, you should
write an academic paper about the problem and present it at an ACM
conference, instead of wasting your efforts on a little mailing list
populated by peons who're merely trying to write applications.
—Jens_______________________________________________
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
