2

I've been doing a few tutorials on Core Data for the iPhone, and none of them seem to work. Luckily, one of the tutorial sites provided source code and one problem that kept popping up (and is hopefully the explanation as to why said tutorials weren't working), was this line:

@synthesize window = _window;

About half a dozen synthesizes like this would auto-generate in my tableview files, but none of the tutorials used them, which caused a ton of errors for me. The line in the working source code is:

@synthesize window;

So, why is this? I've read online that the first version of @synthesize is for memory management purposes, but no one seems to be using it.

PengOne
  • 48,188
  • 17
  • 130
  • 149
user990769
  • 115
  • 2
  • 12
  • This syntax is normally used when you want to prevent "accidental" access to the ivar directly (one possible case is when a variable is lazily created through its assessor method) – Rog Oct 12 '11 at 10:52

4 Answers4

1

The only difference here is in how the instance variable is named when it's auto-generated.

With this version:

@synthesize window = _window;

You effectively get these (assuming you haven't set the @property to readonly):

UIWindow *_window;
- (UIWindow *)window;
- (void)setWindow:(UIWindow *)aWindow;

With the other version:

@synthesize window;

You get this:

UIWindow *window;
- (UIWindow *)window;
- (void)setWindow:(UIWindow *)aWindow;

The second version is equivalent to:

@synthesize window = window;
1

A statement like this:

@synthesize window = _window;

means window is a property that maps to the instance/member variable _window.

Wheras

@synthesize window;

is the same as

@synthesize window = window;
sashang
  • 11,704
  • 6
  • 44
  • 58
0

I've been having the same problems with the tutorials I've been working through.

For my stuff the way I could get it working with minimal change was to add the UIWindow *window; in the header file interface section as this was not being added in by Xcode automatically but was expected by the tutorial stuff.

I then changed the sections where it calls

[window addSubview:tabBarController.view];

to

[self.window addSubview:tabBarController.view];

That seems to work now. The tutorials I'm reading through were based a previous release of Xcode so I'm thinking things have changed. The UIWindow line is not added automatically and Xcode has started using _window for its own stuff.

Would love it anyone could give a clearer explanation though, as I'm kind of stumbling in the dark here.

Dario006
  • 1
  • 1
-2

DO NOT use single leading underscores as a prefix for your ivar or method names. That's an Apple internal coding convention, and they do it so that their symbols won't collide with yours.

If you synthesize a property and tell it to use _window in any subclass of a UIKit class that already has an ivar named _window, you'll be clobbering code in the kit. Other very common ivar names that you might collide with are _delegate, _target, and _view.

NSResponder
  • 16,861
  • 7
  • 32
  • 46
  • 4
    If you're suggestion is not to use the underscores, then how come those variables are getting generated when I use the iPhone templates? They were there before I touched the code. – user990769 Oct 15 '11 at 05:22
  • Great observation! Will NSResponder respond please? – TigerCoding Nov 19 '11 at 05:36
  • I disagree with the whole `_` colliding business. If you declare an ivar as `_delegate` for instance then yes, your ivar might clash, but so would your accessors very likely. As `delegate` => `_delegate` say, then you'd be overloading `- (id)delegate` and `- (void)setDelegate:(id)`. So it's moot that the ivar would clobber the internal one. If you did `delegate` => `delegate_` then your ivar wouldn't clash, but your accessors still would. Also, like @user990769 points out, Apple suggest `_` in the templates. – mattjgalloway Jan 14 '12 at 16:48
  • 1
    For method names, YES, underscores are reserved. For ivars, however, *leading underscores are perfectly fine*. Enough engineers at Apple WWDC have weighed in on this already, including [Chris Hanson](http://stackoverflow.com/questions/837559/when-do-you-make-an-underscore-in-front-of-an-instance-variable#comment651127_837570), also from Apple. In fact, nowadays you don't even need to declare the ivars outright. Just `@synthesize var = _var;` and all is taken care of for you. This also (gently) guides you to [use accessors and dot notation as intended](http://eschatologist.net/blog/?p=160). – Joe D'Andrea Jun 02 '12 at 18:49
  • 1
    See also: [Declared Properties and Instance Variables - Coding Guidelines for Cocoa](https://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html). – Joe D'Andrea Jun 02 '12 at 19:02