I hate doing following
//in file.h
#property (strong) NSString *reuseIdentifier;
//in file.m
#synthesize reuseIdentifier = _reuseIdentifier;
This feels so redundant. I get the distinction of concepts between property in which is named "reuseIdentifier" and memory block that's named "_reuseIdentifier" but why can't the xcode IDE do the work by itself?
I feel like I am doing chores.
It's not been necessary to explicitly implement or synthesize Objective-C properties since Xcode 4.4 in 2012. See the Xcode 4.4 section of the archived "What's New in Xcode" documentation:
Objective-C #properties are synthesized by default when not explicitly implemented.
Related
I understand that #synthesize autocreates the getters and setters for an instance variable. When I specify the = _something part, I understand that this informs the compiler/runtime that I want it to use a particular backing variable for the getters/setters.
Does Objective-C autocreate the _something variable along with my getters/setters or should I be defining that instance variable in my interface/implementation file?
The question is whether #property in the header file and #synthesize in the implementation creates the underlying ivar or whether the ivar has to listed in the header file. Example, in the header file:
#interface SomeClass : NSObject {
NSString *_someString; // Is this needed???
}
#property NSString *someString;
and in the implementation:
#synthesize someString = _someString;
The answer is that it depends on whether or not you are using the legacy or modern runtime. In iOS you are always using the modern runtime so you never need the NSString *_somestring line, but this question is about Mac OS X. For Mac OS X if you are using a 64-bit program on Mac OS X 10.5 or later you are using the modern runtime, otherwise you are using the legacy runtime and need the extra line in your header file. Since there's been some misinformation posted, here is a reference: Objective-C Runtime Programming Guide.
Sorry, misread a part of your question. If you do the #synthesize part with the underscore, you're all good. No need explicitly define an ivar.
I have a class:
#interface MyClass : NSObject
#property (weak) id delegate;
#end
and the implementation:
#implementation MyClass
#synthesize delegate;
#end
When I refactor the code for ARC, it tells me that synthesize of 'weak' property is only allowed in ARC/GC mode. But from what I known, delegate can be 'weak' in ARC, also, if I change it to assign, then it will be converted to unsafe_unretained.
My question is, does it mean the code before conversion(to ARC) should NOT use anything ARC?
Thanks!
It sounds like you might be targeting iOS 4.x
4.x added ARC, but not the full ARC that iOS5+ got. iOS 4.x arc doesn't have support for the "weak" keyword, only unsafe_unretained. If you want to use weak instead of unsafe_retained you will have to drop iOS 4 support.
The difference between "weak" and "unsafe_unretained" is that weak will set itself to nil when it is released, where as unsafe_unretained will hang around pointing to bad (released) memory.
Under what conditions is #synthesize automatic in Objective-c?
Perhaps when using LLVM 3.0 and up? From reading around the net it seems like #synthesize is unnecessary starting with Xcode 4. However I'm using Xcode 4 and receiving warnings when I don't #synthesize a property.
Some of the responses to Why don't properties get automatically synthesized seem to imply #synthesize can be omitted at some point under some circumstances.
Another (old) reference hinting that #synthesize might be automatic at some point in the future.
As of clang 3.2 (circa February 2012), "default synthesis" (or "auto property synthesis") of Objective-C properties is provided by default. It's essentially as described in the blog post you originally read: http://www.mcubedsw.com/blog/index.php/site/comments/new_objective-c_features/ (except that that post describes the feature as "enabled, then disabled"; I don't know if that's an issue with Xcode or if the clang developers themselves have gone back and forth on the question).
As far as I know, the only case in which properties will not be default-synthesized in clang 3.2 is when those properties have been inherited from a protocol. Here's an example:
#import <Foundation/Foundation.h>
#protocol P
#property int finicky;
#end
#interface A : NSObject <P>
#property int easygoing;
#end
#implementation A
#end
int main() { A *a = [A new]; a.easygoing = 0; a.finicky = 1; }
If you compile this example, you'll get a warning:
test.m:11:17: warning: auto property synthesis will not synthesize property
declared in a protocol [-Wobjc-protocol-property-synthesis]
#implementation A
^
test.m:4:15: note: property declared here
#property int finicky;
^
1 warning generated.
and if you run it, you'll get an error from the runtime:
objc[45820]: A: Does not recognize selector forward:: (while forwarding setFinicky:)
Illegal instruction: 4
As of Xcode 4.4, if you don't write #synthesize or #dynamic for a property. the compiler acts as though you had written #synthesize property = _property.
Prior to Xcode 4.4, you must do one of the following things for each property or else the compiler will issue a warning and you will get a runtime error. In Xcode 4.4 or later, you may do any of the following things instead of letting the compiler automatically synthesize the property accessors and instance variable.
Use the #synthesize directive.
Use the #dynamic directive and somehow provide the property getter and (if necessary) setter at runtime.
Explicitly write the property getter method and, if the property is readwrite, the property setter method.
Note that you can use the #synthesize directive (or the #dynamic directive) and also explicitly provide the getter and/or setter methods. But #synthesize provides them if you omit them.
From the New Features in Xcode 4.4 document:
Objective-C #properties are synthesized by default when not explicitly implemented.
So #synthesize is automatic by default starting from Xcode 4.4 with the LLVM 4.0 Compiler.
Also, synthesize will not be automatic if you have implemented the setter AND getter manually. So if you wonder why you can't access _someVariable, having declared #property (...) SomeType someVariable, then it is because you have implemented the setSomeVariable: and someVariable methods.
You can turn off the synthesize warnings by clicking on the project name in the Project Navigator on the left then click All Cobined in Build Settings and then search for synthesize. That should be set to No.
I'm a newbie to ObjC/Cocoa and Mac development in general, and toying with the basics.
The simplistic default template for a new Cocoa application in Xcode 4.2 on Lion looks like this:
// AppDelegate.h
#import <Cocoa/Cocoa.h>
#interface AppDelegate : NSObject <NSApplicationDelegate>
#property (assign) IBOutlet NSWindow *window;
#end
// Appdelegate.m
#import "AppDelegate.h"
#implementation AppDelegate
#synthesize window = _window;
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
// Insert code here to initialize your application
}
#end
I've been using that as a basis for various experiments. Reading up on Automatic Reference Counting (which the project is set to use)—this article, for example—I assumed that one could, perhaps even should replace the assign qualifier for NSWindow *window with weak, but that does not seem to be the case.
The app builds fine, but hangs during startup, with Thread 1: Program received signal: "EXC_BAD_INSTRUCTION" in AppDelegate.m on the line with #synthesize window = _window;.
Changing the qualifier to strong makes the program work, but I fail to see how it would make sense to go from assign to strong. I'd gotten the impression that the pairings for non-ARC/ARC are assign/weak and retain/strong.
A more experienced coder friend suggested that even if the weak qualifier causes window to be prematurely deallocated and some access attempt on it to fail, the exception should be EXC_BAD_ACCESS, not EXC_BAD_INSTRUCTION.
I'm obviously missing something here, but I have no idea what.
EDIT: After a closer look at the crash-time gdb output, the same friend pointed me to this article by Mike Ash that sheds some light on this. Due to reasons beyond my understanding, NSWindow and some other classes that override retain and release can't be the target of zeroing weak references. Interestingly, changing the property declaration to this works:
#property (unsafe_unretained) IBOutlet NSWindow *window;
...even though unsafe_unretained isn't mentioned in Apple's documentation for Declared Properties.
With that, a REVISED QUESTION:
What would be the proper way to go here? Stick to assign despite mentions around the web that it shouldn't be used with ARC? Go for strong? Keep using unsafe_unretained since it seems to work? Something else?
Conceptually, 'weak' is the correct qualifier for a top-level IBOutlet on OS X (iOS is another story). However, to create a proper weak reference that zeroes on deallocation requires cooperation from the Objective C runtime. Classes that override retain or release break this support and so you can't create a weak reference to them. UIWindow is one such class.
That's why the template uses 'assign'. Perhaps it should really use the synonym 'unsafe_unretained' if ARC is enabled. In either case you have a simple weak reference that is not zeroed.
Mike Ash's blog discusses the issue with some Cocoa classes.
Look for it in the middle part of the page: Friday Q&A ARC. Look/Search for the text that starts with "ARC's implementation of zeroing weak references..."
The problem is that some classes don't handle the zeroing weak references that __weak brings. The solution is to go with what the normal ARC templates provide assign.
Well, to answer the second question, even Apple's templates use assign for window when using ARC. So you may be safe for now. But your mileage may vary in the future.
Mike Ash has a very good explanation of what's going wrong here (search for "ARC's implementation"). The gist of it is that the NSWindow class specifically does not support weak referencing: apparently because it relies on overriding retain and release with its own implementations.
I expect there's a few more such gotchas scattered through the legacy Cocoa classes, and these don't appear to be documented yet - instead, you find out through a runtime error. (I expect this will become a compiler warning as well at some point.)
It is more of a complain than a question, though maybe someone has some good points on it. So basically if you want an ivar in your Objective-C class have accessor-methods you have to mention it 3 times
SomeClass* _ivar;
#property (nonatomic,retain/assign/copy) SomeClass* ivar;
#synthesize ivar = _ivar;
and maybe 4th time in dealloc method. So wouldn't it be more convenient if the approach would be like Java-style annotations - in one place before the actual ivar declaration, just something like:
#property (nonatomic,retain,synthesize = ivar,dealloc) SomeClass* _ivar;
this also generates accessor methods, and dealloc - telling to dealloc the ivar in dealloc method.
Actually you don't have to declare ivar - they can be synthesized if you just declare property for them. This should synthesize name iVar for you: (not supported in legacy run-times though - so one of the reasons of this seemingly redundant syntax is for backward compatibility with legacy platforms)
#interface MyClass : NSObject
{
}
#property(copy) NSString *name;
#end
...
#synthesize name;
In new XCode version (4.0 probably) you won't need to use #synthesize as well - properties will be synthesized by default.
So as you see objective-c develops to satisfy your wishes :)
Xcode 4 doesn't automatically synthesize properties unfortunately. But with ARC (automatic reference counting) you no longer need to worry about dealloc and instance variables anymore.