0

I am still learning ..., so for the following property

@property (copy) NSNumber *foo;

What the copy really do? make a copy of the (value of) foo and put it to new place? Just like a copy constructor?

And also to clarify, the following is basically doing a AddRef, right?

@property (retain) NSNumber *foo;
tom
  • 13,143
  • 18
  • 63
  • 120

2 Answers2

1

See the description of properties here: http://cocoacast.com/?q=node/103

copy means that assigning a value into the property will make a copy of the input value.

retain means that you won't get an actual copy; you'll get the same object with an extra retain on it. So if it's modified elsewhere, you'll see the modifications in both places.

For NSNumbers, they are immutable, so copy and retain are functionally equivalent.

StilesCrisis
  • 15,362
  • 4
  • 33
  • 58
0

What the copy really do?

In general, NSNumber is immutable -- I'd expect that copy in those cases would be implemented using retain:

- (id)copyWithZone:(NSZone*)zone {
  return [self retain];
}

And also to clarify, the following is basically doing a AddRef, right?

Well, synthesizing it will add the reference counting boilerplate - the actual operation is more complex and takes the generalized form:

- (void)setFoo:(NSNumber *)arg {
  NSNumber * prev = foo;
  foo = [arg retain]; // << or foo = [arg copy]; if you have specified 'copy'
  [prev release];
}
justin
  • 101,751
  • 13
  • 172
  • 222
  • Of course if you use non atomic vs atomic the boilerplate changes. nonatomic is closer to the above code. Since you did not specify non atomic, there will be @synchronize calls happening under the hood too. http://stackoverflow.com/questions/588866/atomic-vs-nonatomic-properties – Tom Andersen Dec 07 '11 at 00:41
  • 1
    non-atomic ==> code will only be called from a single thread. without the nonatomic keyword, the code is _more_ thread safe, or better thought as you are _able_ to write thread safe code with atomic getters and setters. – Tom Andersen Dec 07 '11 at 00:42
  • @Tom Anderson Yes, I know the example resembles nonatomic implementation (but yours is a fine note for others). The reason for this? This is a beginner Cocoa question, and I said the example is a *generalized* form of what is happening (within the context of the question). – justin Dec 07 '11 at 07:04
  • Some notes about your other comments: 1) nonatomic properties can be thread safe, and they can operate in multithreaded contexts. After all, we were able to create threadsafe concurrent Cocoa programs prior to ObjC-V2. 2) Atomic properties are *not* implemented with `@synchronized`. This is a popular misconception -- it also means that programs which a) use `@synchronized` and b) expect atomic property implementations will also use them have many concurrent design errors waiting to be found. (cont) – justin Dec 07 '11 at 07:05
  • (cont) 3) Atomic properties are not at all a substitute for proper thread safety. They only protect data in a very limited scope. Atomic properties alone are still unquestionably unsafe in concurrent execution -- they only reduce the probability that a threading error will occur (or be exposed) during execution. That's not even desirable - IMO, I'd rather the defect were exposed earlier on and occur more frequently because errors in concurrent programs can be horribly difficult to reproduce. (cont) – justin Dec 07 '11 at 07:06
  • (cont) The short of it is: atomic properties + `@synchronized` are really not good solutions for nontrivial concurrent programs. Under those circumstances, neither atomic properties nor `@synchronized` are ideal. – justin Dec 07 '11 at 07:06