0

I'm trying to pass an ivar pointer to a method and then place a value in that ivar. 

static void placeThis(NSString *thingIn, NSString **here) {
    *here = thingIn;
}

- (void) placeThis:(NSString *)thingIn inHere:(NSString **)here {
    *here = thingIn;

}
- (void) place:(NSString*)thingIn {
    [self placeThis:thingIn inHere:&thing];
    placeThis(thingIn, &thing);
    NSLog(@"How did that go? %@", thing);
}

I don't know if I have the syntax correct. I want to store thingIn in the ivar. Current error is

passing address of non-local object to __autoreleasing parameter for write-back

Is this possible to do, and if so, how?

Note: This is considered a bad idea because it breaks encapsulation. I will use this only in a very local context.

Note: ivar is defined as __strong NSString* thing (the strong is for clarity only).

Dan Rosenstark
  • 68,471
  • 58
  • 283
  • 421

1 Answers1

1

You should use NSString * __strong * as the type of here

And yes, it's not a good idea to do that sort of thing.

Dan Rosenstark
  • 68,471
  • 58
  • 283
  • 421
Analog File
  • 5,280
  • 20
  • 23
  • awesome stuff. Would there be any leaks or other risks, or is it just convoluted? – Dan Rosenstark Aug 10 '12 at 23:41
  • 1
    It's not convoluted. ARC needs to know exactly what kind of pointers it's working with. `__strong` is similar to `const` or `volatile` and `NSString * __strong *` is a pointer to an `__strong NSString*` just as `char*const*` would be a pointer to a `const char*`. – Analog File Aug 11 '12 at 00:26
  • Hmm, I had a doubt, and I checked. It does not work exactly like `const`, but in this specific case it appears to. The actual details of how it works are here http://clang.llvm.org/docs/AutomaticReferenceCounting.html#ownership.spelling – Analog File Aug 11 '12 at 00:35
  • Okay, looks good. So the other thing is, why the blanket "it's a bad idea to do this?" People do worse stuff with macros all the time. – Dan Rosenstark Aug 11 '12 at 05:31
  • Because of what I can only call the "spirit" of ObjC. Changing an ivar should be considered an implementation detail of a higher level operation (often accessing an attribute of the class). Except from inside the class implementation itself, where it may be necessary to access the ivar directly in some circumstances, you should not access ivars. You should sent a message to the class instead. This lets the class add extra logic to the operation and subclasses change the meaning of it. Examples of extra logic may be logging and/or KVO support. – Analog File Aug 11 '12 at 08:20
  • Found this http://stackoverflow.com/questions/9567202/obj-c-error-trying-to-store-indirect-pointer-as-ivar and the reply agrees with me. Breaks encapsulation he says, which is the correct name for the concept. And it is bad design. – Analog File Aug 11 '12 at 08:27
  • Exactly: it breaks encapsulation if you do it from another class. If you do it from the same class, it might actually make your code more readable and help you to avoid repetition. – Dan Rosenstark Aug 11 '12 at 12:30