Single and double underlining differences in @synthesize declaration

Question

In a recent Xcode 4.3 project template, some @synthesze declared as:

 @synthesize window = _window; @synthesize managedObjectContext = __managedObjectContext; @synthesize managedObjectModel = __managedObjectModel; @synthesize persistentStoreCoordinator = __persistentStoreCoordinator; @synthesize navigationController = _navigationController; 

Some of them have a double underscore ( __ ) as a prefix. Why?

Anything related to the readonly attribute?

 @property (strong, nonatomic) UIWindow *window; @property (readonly, strong, nonatomic) NSManagedObjectContext *managedObjectContext; @property (readonly, strong, nonatomic) NSManagedObjectModel *managedObjectModel; @property (readonly, strong, nonatomic) NSPersistentStoreCoordinator *persistentStoreCoordinator; @property (strong, nonatomic) UINavigationController *navigationController; 

Answer 1

They probably shouldn't use double underscores if they are intended to be used in your own program. I expect this to be just the oversight of the person who wrote this sample template. In practice, it is unlikely that they will cause any problems.

Standard C reserves all identifiers starting with a double underscore for its own implementation. Since Objective-C is a superset of C, you should not use these identifiers in Objective-C programs. From Specification C, Section 7.1.3 Reserved Identifiers :

All identifiers beginning with an underscore and an uppercase letter or other underscore are always reserved for any use.

Answer 2

Perhaps in this case. In general, an apple tends to use _ prefix names to refer to an external copy of a variable (for example, when it is passed as a function or direct ref as opposed to a property). The person who wrote this code probably thought he was smart by adding an extra _ to read only, but this is usually bad practice, since C reserves __ for specifying compiler directives.

I have never seen a C compiler complaining about __vars, and LLVM does not seem to mind, but this is probably not a good practice.