On Mon, Nov 30, 2009 at 9:57 PM, Jeff Laing <jeff.la...@spatialinfo.com> wrote:
>> > Why would you not just do:
>> >
>> > [cell->image retain];
>> >
>> > That makes it a lot clearer to me - since it was a bitwise copy,
>> > cell->image and image are identical values whereas the assignment
>> > looks like you are changing something.
>>
>> Because it may *not* have been a bitwise copy. The superclass may have
>> either done a bitwise copy of the whole object (the common case, I
>> believe) or it may have only copied its *own* instance variables (in
>> which case, cell->image will be nil). It's because of this uncertanty
>> of which method the superclass uses that this, admittedly ugly, bit of
>> code is used.
>
> Ah, the penny drops. You're saying that the superclass might have used,
> pseudo-codingly,
Yes; I've put some slightly less-psuedo code below :)
> memcpy( newobj, oldobj, sizeof(typeof(oldobj)) )
More accurately, the superclass' -copyWithZone: would look something like:
-(id)copyWithZone:(NSZone*)zone {
MySuperClass *result = [[self alloc] init];
/* Set up MySuperClass' instance variables, but don't touch
subclass' instance variables; leaving them set to nil*/
return result;
}
>
> rather than
>
> memcpy( newobj, oldobj, sizeof(oldclass) )
Or, in this case, it would look like:
-(id)copyWithZone:(NSZone*)zone {
MySuperClass *result = NSCopyObject(self, 0, zone);
/* Fix up MySuperClass' instance variable retain counts, but don't
touch subclass' instance variables; leaving them set to valid, but
under-retained values*/
return result;
}
> and thus the newly created object *might* have essentially random bits
Not random bits; there are only two possible states: it will either
have nil, in which case:
[cell setImage: image] would be just fine and:
[cell->image retain] would not work
Or an un-retained bitwise copy of the original's value, in which case:
[cell setImage: image] would not work (i.e. cause an under-retain) and:
[cell->image retain] would be fine
cell->image = [image retain], however, works in both cases.
> in the "subclass" instance variables. I was assuming it was always going to
> use the latter - seems
> stupid to use the former under any circumstance. It's never going to be
> valid for a superclass to
> make assumptions about the behavior of its subclasses, and thus it's
> completely irrational to
> present them with an indeterminate state, when it could just as easily
> promise "all your instance
> variables will be nil".
True, but history is a powerful force. This is also why the
documentation on NSCopyObject states:
"This function is dangerous and very difficult to use correctly. It's
use as part of copyWithZone: by any class that can be subclassed, is
highly error prone. Under GC or when using Objective-C 2.0, the zone
is completely ignored.
This function is likely to be deprecated after Mac OS X 10.6."
--
Clark S. Cox III
clarkc...@gmail.com
_______________________________________________
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
