Cocoa mail archive
Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
FROM : Michael Ash
DATE : Thu Feb 07 23:58:53 2008
On Feb 6, 2008 10:52 PM, Ben Trumbull <<email_removed>> wrote:
>
> You cannot message a void* without type casting. The compiler won't
> let you. The compiler treats objects differently. Further, there is
> no way for you to accept an arbitrary void* parameter and prove at
> runtime it is in fact capable of dispatching messages (i.e. has an
> isa at offset 0). Yet I always know I can message an id.
More nitpickery here....
You can certainly message a void * without type casting. The compiler emits
a warning, but warnings are not errors. I would not be surprised if this
were not the case in ObjC++, I only tried plain ObjC.
And you certainly cannot know that you can message an id. Aside from obvious
pathological cases such as (id)42, consider the extremely common problems we
see on this list all the time where people mess up their memory management
and end up with id variables which crash when messaged.
It's often convenient to ignore these facts and act as though ObjC is a safe
OO language, but the fact is that it is C and it allows all the dumb (and
powerful) stuff that C allows.
For any arbitrary id, I can invoke -class without crashing.
This is untrue. You can only invoke -class safely if the target implements
it. Anything which inherits from NSObject will, but it is trivial to create
a root class which doesn't respond to -class. And there's no reasonable way
to find out if it responds to -class or not, because -respondsToSelector: is
*also* not guaranteed to exist! The ObjC runtime functions can try to tell
you, but they can give a false negative in the case of classes which handle
these messages via forwarding. Once again, it's convenient to act as though
all ObjC objects conform to the NSObject protocol, but it is not actually
enforced.
Mike
DATE : Thu Feb 07 23:58:53 2008
On Feb 6, 2008 10:52 PM, Ben Trumbull <<email_removed>> wrote:
>
> You cannot message a void* without type casting. The compiler won't
> let you. The compiler treats objects differently. Further, there is
> no way for you to accept an arbitrary void* parameter and prove at
> runtime it is in fact capable of dispatching messages (i.e. has an
> isa at offset 0). Yet I always know I can message an id.
More nitpickery here....
You can certainly message a void * without type casting. The compiler emits
a warning, but warnings are not errors. I would not be surprised if this
were not the case in ObjC++, I only tried plain ObjC.
And you certainly cannot know that you can message an id. Aside from obvious
pathological cases such as (id)42, consider the extremely common problems we
see on this list all the time where people mess up their memory management
and end up with id variables which crash when messaged.
It's often convenient to ignore these facts and act as though ObjC is a safe
OO language, but the fact is that it is C and it allows all the dumb (and
powerful) stuff that C allows.
For any arbitrary id, I can invoke -class without crashing.
This is untrue. You can only invoke -class safely if the target implements
it. Anything which inherits from NSObject will, but it is trivial to create
a root class which doesn't respond to -class. And there's no reasonable way
to find out if it responds to -class or not, because -respondsToSelector: is
*also* not guaranteed to exist! The ObjC runtime functions can try to tell
you, but they can give a false negative in the case of classes which handle
these messages via forwarding. Once again, it's convenient to act as though
all ObjC objects conform to the NSObject protocol, but it is not actually
enforced.
Mike
