Those who disagree with me implicitly acknowledge
I do not think that those who disagree with you must acknowledge your
two premises implicitly or explicitly.
A) The compiler is generating code that violates the C standard.
You put a lot of effort into claiming that it's a given that the
compiler is generating bad code and that the point is "not up for
debate". I agree that your claim is not open for debate, it is
demonstrably false.
It is not the compiler that is generating code that violates the C
standard. It is the action of the garbage collector thread, and the
semantics of associated library routines like NSAllocateCollectable,
that are at odds with the the semantics of the C described by the
standard (the standard that does nothing to take the actions of a
garbage collector into account).
If you were to do something evil like set up your running application
to kill the Garbage Collector thread prior to executing the code that
the compiler has generated, that would execute in accordance with the
standard. The compiler cannot be held responsible for the actions of
the Garbage Collector thread (whether it is an optimizing compiler or
not).
From the standpoint of the compiler and the standard, the garbage
collector thread and its libraries are rogue agents that work outside
the law.
B) Because of this, it significantly complicates writing code that
uses garbage collection.
Well, having shot holes through premise A we could ignore premise B
altogether. We could also devolve into pointless and petty arguments
over subjective opinions like those expressed in the fragment
"significantly complicates".
I suppose you might argue that using the Garbage Collector with
arbitrary C code, when using common C pointer idioms, is more
complicated than using it in the context of those problems that it was
designed to solve. Then again, what technology doesn't get more
complicated to use once you apply it outside of the context of the
problems it was designed to solve?
.. there is no way for you to write code at the C source level that
explicitly and intentionally ensures that lifetimes of the "base"
pointers
continue for as long as "derived" or "interior" pointers need to be
valid.
As Adam on Mythbusters might say "Well there's your problem, right
there!"
The Mac OS X garbage collector is not designed to simplify memory
management at the "C source level".
I've seen _hours_ of presentations at WWDC and the "Tech Talks" which
focus on the esoteric way that the garbage collector behaves when you
combine garbage collected Objective-C objects with lower-level C code.
In those instances, the system provides some low level routines for
solving very specific problems when Objective-C is interacting with C
code. Those routines might be misconstrued as providing general
support for low level memory management in C, but that would be an
erroneous conclusion.
Incidentally, you CAN write code at a low level that "explicitly and
intentionally ensures the lifetime of the base pointer". Use the
NSGarbageCollector routines disableCollectorForPointer: and
enableCollectorForPointer: on that base pointer and you can control
its lifetime almost as closely as you would like.
(Admittedly, however, that's at the "Objective-C source level", and
not the C level).
If GC effort and difficultly is ever greater than manual memory
management, what's the point?
What's the point of driving a car if you have to get off the freeway
and drive on residential streets? What's the point of using computers
if the applications can crash?
"The point" is that the majority of the time GC greatly simplifies
memory management of Objective-C objects. In special cases if you
have to interact with lower level C code you might have to accept the
complexity afforded by the lower level routines, routines like
NSAllocateCollectable (which is designed to allow you to allocate C
structs in such a way that Objective-C pointers can be stored inside
them without the objects being collected).
I mean, seriously... when using Mac OS X GC, it's no longer enough
to write source code that's correct - you also need to make sure the
code that comes out of the optimizer reflects the intent of the
source code and that crucial bits haven't been dead code eliminated.
Seriously... If you make the decision to use of the garbage collector,
then in _addition_ to making sure that you write source code that is
correct according to the semantics defined by the language standard
and the compiler, you must _also_ make sure that the source code you
write is correct with respect to the semantics of the garbage
collector and associated library routines.
To mangle a popular movie quote, "If you opt in to Garbage Collection
you are invoking great power and with greater power comes greater
responsibility".
When you drop down to the "C source level" and start working with raw
pointers and pointer arithmetic, you have to pay more attention to the
collector, your responsibility is even more burdensome.
An excerpt from the paper "A Proposal for Garbage-Collector-Safe C
Compilation" (circa 1992, available at
http://www.hpl.hp.com/personal/Hans_Boehm/gc/papers/boecha.ps.gz )
An interesting paper, and mostly irrelevant. This paper concerns
itself with Garbage Collectors for C applications and tries to create
a robust garbage collector that supports common C pointer idioms. Mac
OS X's garbage collector is not a general purpose garbage collector
for C. It never has claimed to be and should not be treated as such.
The Mac OS X garbage collector concerns itself primarily with the
memory management of Objective-C objects. That it provides some
extensions for working with memory at the C level in special instances
is a testament to the flexibility of the system, but on the whole the
goals of the Mac OS X garbage collector, and the goals of the
collectors described in the paper are different.
I think you owe me where the following limitation is explicitly and
unambiguously documented:
This is a public mailing list and the posters here "owe" you
nothing. :-)
__strong char *cStringP = NSAllocateCollectable(1024, 0UL);
strcpy(cStringP, "Hello, world!-Goodbye, world!");
__strong char *otherCStringP = memchr(cStringP, '-', strlen
(cStringP));
In particular, why 'cStringP' must remain live and visible and that
'otherCStringP' is not enough to keep base pointer allocation at
'cStringP'
live.
I've been over the documentation several times, and I definitely
skimmed parts of it (like the section on finalize), but I can't find
anything.
Reread the documentation and pay attention to how the garbage
collector works. In particular pay attention to the discussion of how
the decision is made to collect memory based off of the "roots". On
the whole the reason your code is problematic becomes pretty clear.
Particularly when you pair it with the warning given about the
optimizer and the "Interior Pointers" example given in the
documentation. I admit it's not an explicit regurgitation of your
particular code sample, but it does seem pretty straightforward.
The published documentation on NSAllocateCollectable is pretty sparse
and could probably be improved. It could probably be clearer if the
documentation went out if its way to point out that
NSAllocateCollectable returns a "memory object" and "just arbitrary
memory".
I will grant you that some better documentation on the esoteric
interaction of the Garbage Collector with low-level C code would be
welcome. If not, then naïve C programmers might assume the garbage
collector to be a general purpose tool for managing arbitrary memory
and could get themselves into just the sort of trouble you've pointed
out.
If you beef is with the documentation, please visit the page with the
"Interior Pointers" topic on it and scroll to the bottom. Find the
"Did this document help you" links and choose either "It's good,
but..." or "Not helpful…" as you feel is most appropriate. As for
revised documentation of the proper use of the Foundation APIs
associated with the garbage collector. Alternatively (or even better,
in addition to that) you can visit bugreport.apple.com and file a bug
agains the documentation._______________________________________________
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
