On 01/12/2009, at 6:06 PM, Clark Cox wrote:
> 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
> hig
On Mon, Nov 30, 2009 at 9:57 PM, Jeff Laing 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 s
> > 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 cop
Sent from my iPhone
On Nov 30, 2009, at 17:26, Jeff Laing
wrote:
In most cases, yes. However, copyWithZone: is special, the
superclass'
implementation just blindly copies all of the raw bits in the source
object to the newly created one. If you were to use the normal
-setImage: call, th
Thank you for your explanations, Clark, Jeff and Graham.
I think i will go now and read a C book (yes, I know I should have
read it by now) because it seems to me I have been missing something.
Bye
Mario Kušnjer
mario.kusn...@sb.t-com.hr
+385957051982
_
On 01/12/2009, at 12:30 PM, Mario Kušnjer wrote:
> This could not be like this, right ?
>
> [cell image] = [image retain];
No, because [cell image] returns a value, it does not set a value. You might
consider doing this though:
[cell setImage:image];
Clark is right that if the copy was a bi
On 01/12/2009, at 12:26 PM, Jeff Laing wrote:
>> In most cases, yes. However, copyWithZone: is special, the superclass'
>> implementation just blindly copies all of the raw bits in the source
>> object to the newly created one. If you were to use the normal
>> -setImage: call, that old value woul
cell->image is semantically identical to (*cell).image. That is, it's
directly accessing the instance variable "image" of the object "cell"
This part is what trouble's me.
cell->image = [image retain];
This could not be like this, right ?
[cell image] = [image retain];
Mario Kušnjer
mario.
> In most cases, yes. However, copyWithZone: is special, the superclass'
> implementation just blindly copies all of the raw bits in the source
> object to the newly created one. If you were to use the normal
> -setImage: call, that old value would be released one too many times.
> Assigning to the
2009/11/30 Mario Kušnjer :
> Hi !
>
> I have some trouble understanding this implementation:
>
> - copyWithZone:(NSZone *)zone
> {
> ImageAndTextCell *cell = (ImageAndTextCell *)[super copyWithZone:zone];
> cell->image = [image retain];
> return cell;
> }
>
> It is from the Apple's sample
Hi !
I have some trouble understanding this implementation:
- copyWithZone:(NSZone *)zone
{
ImageAndTextCell *cell = (ImageAndTextCell *)[super
copyWithZone:zone];
cell->image = [image retain];
return cell;
}
It is from the Apple's sample code.
First question is why there is no
11 matches
Mail list logo
