small medium large xlarge

Back to: All Forums  Using Map Kit
17 Jul 2009, 17:24
bil (2 posts)

i’m new to objc and coding for mac/iphone in general, so please forgive, yet entertain, a totally noob question…

i noticed in the mapkit video and source files, that you follow the pattern of:

declaring instance variables in the interface with an underscore, e.g.:

MKMapView *_mapView;

then, you assign the property without the underscore, e.g.:

@property (nonatomic, retain) IBOutlet MKMapView *mapview;

and then synthesize with an assignment, e.g.:

@synthesize mapView = _mapView;

later in the code, you refer/use/test both flavors of the _ and non _ variables.

i can not find any relevant info or clues to why you might be doing this and am left wondering. what advantages or reasons are there to doing it in this way… or am i missing something entirely due to being so new to this? unfortunately, for as helpful as they were, your objc vids didn’t cover anything in this area.

keep up the great work, and thanks!

26 Jul 2009, 12:03
codiac (4 posts)

I have the same question. Can you please explain this use of ‘_mapView’ and ‘mapView’, etc. ? Thank you.

28 Jul 2009, 17:50
Bill Dudney (916 posts)

Hi All,

Sorry to be so late in responding I’ve been traveling for 11 days with limited net access.

This is a way to distinguish between using the get/set method pair an using the instance variable. In the .h file we declare the ivar as MKMapView *_mapView; and the property with @property (nonatomic, retain) IBOutlet MKMapView *mapView;

That property declaration means that if we use the set method that we should expect the argument will be retained by the receiver. In other words, when we exectute this line of code;

[vc setMapView:aView];

The ‘vc’ will retain ‘aView’.

A property does nothing more than give us the get/set method pair.

So when we use the property notation vc.mapView = aView; the set method is actually being invoked.

If however we use the ivar instead of the property we will not get a retain. i.e. _mapView = aView will not retain ‘aView’. If aView has no other retains it will be released and when its released we will have a pointer to a freed object. Which of course is very bad.

Having the property and the ivar named differently helps us to avoid this all to common mistake. If we were to write mapView = aView; the compiler would tell us the mapView is undeclared and then we’d know we forgot the ‘self.’ from the front of that statement. If we had the ivar and the property named the same we’d not get a compiler error and no retain so we’d likely end up running thinking everything is fine.

Hope this helps!

29 Jul 2009, 04:11
codiac (4 posts)

Thank you for the explanation. I’ve seen this convention used by others and never understood the reasons. This clears it up well.

I appreciate your teaching style and hope you’ll continue creating more MapKit (and other) tutorials.

05 Aug 2009, 07:06
Ned Hogan (3 posts)

Just a note that this is a bit confusing. A little UNIX history, in order to avoid name space collision between the UNIX API’s and your code, the convention was to use _ for OS library, and __ for compiler libraries, or at least that what I recall when I 1st started programming in C and UNIX. I did hear a talk recently where it was suggested not to use _ in your vars to avoid name space issues on the iphone. The exception appears to be the getter/setter methods as you have clearly explained. Perhaps I misunderstood or the person mis-spoke, but other than the getter/setter, it is a good idea to avoid the use of _ as a best practice, or this is more of a tradition in C than Cocoa?

05 Aug 2009, 13:33
bil (2 posts)

thank you for the detailed reply, bill. for some reason RSS just now picked up the new posts.

although your explanation was quite good and helped clear up some of the confusion, i agree with ned that it is a still bit confusing- for the same reasons he stated. most of my recent coding experience has been in C for linux, so the conventions ned mentioned are part of what is confusing, when applied to objC and cocoa.

am i interpreting your explanation correctly that this convention is mostly about memory management and assuring the objects get properly retained?

as this is a convention you often use, i definitely recommend covering it to some degree in your upcoming iphone app book. i suspect i am not the only one who looks at someone else’s code and wants to understand the why behind doing something and not just implement it because that what “everyone seems to do”. i also suspect that a significant percentage of new iphone coders do not come from a cocoa background and it would serve them well.

definitely looking forward to the upcoming book being finalized and ready for purchase!

thanks again.

05 Aug 2009, 16:05
Ned Hogan (3 posts)

Thanks for the follow up bil. Glad I am not the only one who recalls this convention. I believe us old dogs will need to learn new tricks, the recently updated “Cocoa Design Patterns” implies the underscore as a design pattern as well. To my trained eye this sends up a red flag, which I need to ignore if in the right context. I am certain that if you make a habit in general of implementing _ in you code, you will run into name space collisions with the OS Libraries, which are UNIX based.

You suggestion makes sense, not that Mr. Dudney needs to change his code, but a word of warning in the book would be appropriate about the dangers of name space collisions as Cocoa is an extension of C.

05 Aug 2009, 18:10
Bill Dudney (916 posts)

Hi Ned & all,

Thanks for pointing this out. It’s a bit late to change this kind of thing.

However you won’t end up with name space collisions because the ivars are in a different name space than the unix os libraries.

05 Oct 2009, 20:35
Tom H (8 posts)


This is excellent – thanks for the explanation. I picked up the Map Kit vid last week and was a bit puzzled by this.

If I’m following correctly both the _mapView and self.mapView point to the same object. So there is no difference in the following:

MKMapView *b = _mapView;

MKMapView *b = self.mapView;


Thanks again


06 Oct 2009, 10:23
Bill Dudney (916 posts)

Hi Tom,

the value of b will be the same in both, however the second (self.mapView) will invoke the get methods. So for example if you were lazily creating the map view, the first method would get nil and the second (since it invokes the get method) would return the lazily created map view. Not that we are creating it lazily here, its just an example to illustrate the difference between the two statements.

Good luck!

You must be logged in to comment