Gathering up a few loose ends...
On 17-Apr-10, at 11:11 AM, Paul Sanders wrote:
I reckon my scheme might actually be faster Ben, if you benchmark
it. Without the assert it's just a method call and a memcpy, which
the compiler knows the size of and can therefore optimise. Only you
can decide whether either approach is worth the risk.
I think my approach, with the excellent modifications suggested by
Ken Thomases, makes me less nervous than the others proposed, since it
touches only my own ivars and makes no assumptions about the nature of
the rest of the bits in the object. You may be right that your way
would be faster, Paul, but the ongoing discussion indicates to me that
it is sensitive to undocumented internals of NSObject's ivars and
behavior -- currently with respect to retain count, but in principle
Apple could do whatever they liked under the hood, up to and including
adding a new pointer to NSObject with ownership semantics. The
documentation pointed out thus far falls well short of a guarantee
that they will never do such a thing, to my ears. Similarly, the
custom allocator idea seems vulnerable; as Ken pointed out, some
knowledge of how the retain count is implemented might be necessary,
for example.
On 17-Apr-10, at 10:53 AM, Uli Kusterer wrote:
The question is: Is it documented as a fact you can rely on that
this is the case? If not, I at least wouldn't rely on it for
shipping code. Even if it was for an "at home" project I'd think
about it long and hard. Tracking down subtle memory bugs caused by
Apple deciding to move the reference count into an NSObject instance
variable after all doesn't sound like a fun occupation.
I could not agree more. :->
On 17-Apr-10, at 10:54 AM, Paul Sanders wrote:
AFAIK, CF objects store the retain count in an "ivar" (or a struct
field to be exact) and
standard Obj-C objects ref count is stored in an external hash
collection (CFBasicHash on 10.6).
One might get away with it then, as presumably the hash key is the
address of the object and that is constant for the lifetime of the
object. Weird implementation. Expensive, in terms of CPU cycles,
for retain and release. The retain count should be an iVar of
NSObject, seems to me.
It does seem odd; I would love to hear the motivation behind this
design. Knowing how smart the guys who designed this stuff are,
though, I'm pretty sure there's a good reason. :->
It's worth noting that many Cocoa objects, IIRC, store their retain
count in a different way than NSObject. Many keep a couple of bits in
a bitfield somewhere, capable of storing retain counts up to some
small maximum count, and then use a flag value in that bitfield to
indicate "retain count is stored externally" to handle the overflow
case. This makes retain/release much faster than the base
implementation. I've done this myself, in fact. Fun stuff. :->
Thanks everyone for the posts, it has been an interesting
discussion and has improved my code!
Ben Haller
McGill University
_______________________________________________
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
