Weekly Recap
So, I've had this post brewing for the past few days, mostly because of the irritation that it's caused me.
I've been torn between being overly technical in my blog or just giving the high level details of my progress during this venture. Unfortunately, I think I'm going to have to be really geeky in here. I wanted to stay pretty high level so most people could follow along, but some things that I've run across this week have vexed me pretty heavily and I feel the need to explain them in depth so that any .Net developer that does try and make this transition in the future has a good point of reference. So, in an attempt to stay at a fairly high level, I'll brush with wide strokes today and see if I can get a somewhat satisfactory post out on what I think is a pretty important topic.
So, This week's recap first and then the meat of the week.
- Lots of progress, although a lot of the stuff this week was Xcode interface related stuff.
- Tweaks to the IDE.
- Tweaks via command line to setup some auto commenting stuff. (if anyone is interested, comment and I'll post more on this one)
- Basic tour of the debugger
- Basic source file organization with multi-file projects (read, how to deal with REAL applications, not just 'hello world' apps)
- Creation and use of my first set of real live classes in Objective-C (lots of interesting cursing to do here ;) See rant to come. )
- First real nightmarish roadblock. Objective-C/Cocoa's Boxing and Un-boxing
Get in the Ring - Objective-C/Cocoa's Boxing and Un-boxing
A few definitions first from a .Net developer's perspective:
- Primitive Type
- - Any data types directly supported by the compiler. These map directly to types that exist in the base class library.
- Value Type
- - Value types are primitive types that are mapped directly to the Framework Class Library. From a memory management standpoint, all value types are stored on the stack.
- Reference Type
- - Any object type that is not a primitive type. These objects are created on the heap from a memory management standpoint using the new keyword and will return the memory address of the given object.
- Boxing
- - To be very brief, Boxing is nothing but converting a value type object to a reference type object. Sometimes the .Net compiler will allow implicit conversions for this.
- Un-boxing
- - Again, in brief, Un-boxing is a conversion of a reference object back into the appropriate value type object. This is typically an explicit conversion.
- Auto-boxing
- - a feature that some languages provide that will automatically convert primitive types to the corresponding wrapped types and back.
As I said before, I want to try and stay a bit more high level and out of the code examples and the like, but I'll add links to relevant sites if I think they are needed (and they are here.) This particular topic however, bothers me, a lot. See, I went into the Objective-C world from a C# mindset and had put my old C++ development mindset on the back burner. I had put aside things like pointers and memory management and garbage collection. I'd left that world behind and let the framework deal with it for me. I'd just code merrily away and magic would take care of those things for me from now on right? *shakes head* What? Really? I mean, I know better, but I guess I let myself get swept away in it and just didn't really bother with what was going on under the covers.
I left Microsoft do the heavy lifting and I just merrily went along my 'Business Applications Development' way. Most business apps don't need high scale performance tuning anyway. I have people that tell me that if an application runs in an hour that is an acceptable time frame, for a report. *shakes head* Anyway. I digress. So, this week, while going through the motions of learning the new language and creating my first real application in Objective-C, objects were finally needed. Real objects and collections of said objects, but wait. What's this? Boxing and Un-boxing? I... Have to write my own, surely you... really? No... really?
Suddenly, it hits me. I'm not in Microsoft's world anymore. Auto-boxing, doesn't exist here. Objective-C and Cocoa? Yeah. Don't do it. I'm writing real code, in real editors, on platforms that Microsoft doesn't control. I have to do things the old fashioned way. I have to work on writing it all. Not to say it's old fashioned, just to say that I became too self-reliant, or rather too Microsoft-reliant, in this case.
So, with all this in mind, here's what I ran into: primitive types cannot be stashed directly into NSArray or NSMutableArray, you first have to 'wrap' them. They have to be
boxed into an appropriate wrapper class, either NSNumber, NSValue, or, I suppose, NSNull, but special cases and what not. There are some objects that will assist you, but mostly you are responsible for handling it all on your own. Anyway. Then, when you want to later use said values, you will have to
un-box these values back into the appropriate primitive types.
In the .Net world, the use of value types over reference types is preferred. This is due largely in part to reference types coming off of the heap, which means more to manage in the ways of cleanup in memory management and garbage collection. Whereas with value types, there is less to worry about memory management concerns because it is all based on the stack.
Here, in Objective-C land, it would appear that it's kind of a harder call, you have full control of the memory, so you have the adage from Spiderman to keep in mind 'With great power, comes great responsibility'. I may have to reserve judgment around memory usage until I delve a bit further in on this but, so far, it would appear that the use of value types vs reference types is mostly moot and you just need to be especially careful on your conversion code.
Most .Net developers I know usually take memory management and garbage collection for granted unless they are hard core into performance tuning or are language freaks and want to know everything about the framework. I know about a dozen .net guys personally who wouldn't be able to tell me the answer to
"Define [the term(s)] Boxing & Un-boxing as they relate to the languages in the .Net framework." To be honest, until about 4 years ago, I couldn't have cared one way or another myself. It wasn't until I got an application with what looked like a memory leak that I started looking into it.
So, with that said, C# and VB.Net folks, take it to heart: this stuff is important. Learn it now. It will make you more efficient in your current careers. It will make you think about things in more memory-efficient manners or should at least start you down that path. It will also prepare you better for the switch, if you plan on making one. You managed C++ folks doing .Net, you already know all this and I'm just preaching to the choir. Stop laughing at me. ;P
For .Net developers reading along that are interested in learning more about the underpinnings of Boxing and Un-boxing and how it affects you on a day-to-day basis, here are a few good resources. Please, please, please, go read them. It really is important to understand it and it really will help you get to that next level.
http://aspalliance.com/986_Boxing_and_Unboxing_in_NET.1http://www.dnzone.com/go?377http://msdn.microsoft.com/en-us/magazine/cc301569.aspxLabels: C#, Development, iPhone
