Objective-C MIN and MAX #define wonkiness

Here’s a little odd thing I discovered when trying to use the MIN and MAX macros defined in NSObjCRuntime.h.  I had the following code (simplified):

const int MAX_OBJECTS = 10;
int numObjectsToRemove = MAX(0, myObjectArray.count - MAX_OBJECTS);

Let’s say myObjectArray.count is 1.  What would you expect numObjectsToRemove to become?

0, right?  Because (myObjectArray.count – MAX_OBJECTS) == (1 – 10) == –9, and 0 is clearly greater than –9.  But you’d be wrong.  And so was I.

You see, apparently, since the count member of NSArray is an unsigned int, the entire expression gets treated like an unsigned int.  So, since –9 in unsigned form is actually a very large number, it’s considered greater when compared to 0.  But as if that wasn’t bad enough, when it gets assigned to numObjectsToRemove, it gets treated like a normal signed int again, so its value becomes –9 again.  And you’re left wondering why –9 is considered greater than 0.

The simple fix is to force the macro to treat the whole expression like an int with a simple cast:

int numObjectsToRemove = MAX(0, (int)myObjectArray.count - MAX_OBJECTS);

More Mac/iPhone development updates

I have several posts in one of my other blogs that are applicable to this one, so I suppose I will fix one of them up and post it here, so as not to appear M.I.A. The following is a follow-up to some landscape-mode issues I've been having with iPhone development; specifically, if I apply a transform to a root level screen in my app, any child screens added 1) will not have that transform applied in the iPhone simulator, as I would expect, but 2) *will* have that transform applied on the actual device:


I've at least found a good temporary solution for the landscape issues, and I've been progressing with learning Objective-C / Cocoa / UIKit / etc. but not to the point at which I can concretely delineate between each of these terms. I'm also struggling a bit but getting the hang of several things.

I finally installed a third-party mouse configuration software so that I can get more than a kindergarten level of control over my mouse sensitivity.

I'm getting the hang of the MacOS app launching model, the dock bar and how it represents running versus non-running programs, the "Finder" file browser and its quirks.

XCode is like Visual Studio Lite, or perhaps "Visual Studio Gimped". I've chatted endlessly on IRC with people who gladly praise XCode over Visual Studio, but I wonder if they've used VS2005 or greater. It's just no comparison; there are redundant windows/panels everywhere, the debugger runs in a separate tiny window, though you can resize it, covering your other windows. The expression watcher is nowhere near as powerful as Visual Studio's, and Intellisense (or its equivalent) is weaker in its implementation, requiring more keystrokes for simple tasks.

Speaking of the tiny debugger window (obviously resizable), this is a common observation with MacOS. It seems the norm to be expected to manually drag windows around and place them as you need them; stretching them to just the right extents, etc. In Windows my usual mode of operation is to only do that when I'm copying files from one explorer window to another. When I'm running apps, I generally switch to the app, then maximize the window if it isn't already maximized. Windows seems to work well with users who are used to this behavior. MacOS doesn't seem to be expecting it; hence, I'll find that apps have lots of little "helper" windows that are expected to be resized to comfortable dimensions for the particular user at that particular time. This is not how I want my apps to work. Visual Studio supports this, but also a very extensive docking scheme so I can have all my windows docked where I want them instead of floating about in the ether, always getting in the way of content behind them, or else getting hidden themselves when I click somewhere else.

Again I find it ironic that so much of what makes the iPhone dominant over Windows Mobile is the same that makes Visual Studio dominant over XCode and the general Mac development situation. Of course, I am trying very hard not to bias my arguments with my existing familiarity with Visual Studio. There's still much more to learn.

Other factors which add major hurdles include simple things like the feel of the keyboard. It's no longer Ctrl-C, it's Command-C, etc., not to mention completely different dev environment hotkeys. And on my particular keyboard, the Esc and F-keys are tiny.

I finally bit the bullet and sacrificed dual-monitors on my PC in order to have a dedicated monitor with a DVI input from my Mac. I also switched placement of my keyboards/mice so that my Mac is in my primary workspace on my desk, and my PC is riding shotgun. This will encourage me to give my Mac some more love.

Update: The lack of multi-monitors with my PC is getting annoying, but I bought a new keyboard for my Mac, realizing that PC keyboards usually work just fine. This has been so great for my sanity and has filled me with some extra spirit that was lacking the past few days.

Microsoft development, I will never forsake you

Warning: The following post was originally posted to a development blog of mine, and is thus heavy on the programming jargon and ranting.  Feel free to ignore for your sanity's sake.

For the past few weeks I've found myself jumping from one shiny project to the next.  I was enticed into trying game development using Silverlight, which I still regard as an exciting technology with lots of potential, but my heart just isn't in it.  If I targetted that platform, I'd be doing so out of pragmatism instead of passion; that is, I know there's a potential market there, but I wouldn't enjoy the work.

My latest flavor-of-the-month project has been game development with the iPhone SDK, whose Kool-Aid I drank in one giant gulp.  The iPhone is amazing.  The interface is slick and intuitive; the app store is exciting and full of great (and not-so-great) apps with a promising revenue model for independent developers, and the development platform is... utter shit.  Without breaking the NDA (I hope), let me just say that just about everything about the iPhone development story is inferior to what Microsoft has to offer.  I don't claim to be an expert after only about a week of experience (albeit with many hours put in), but here are some gripes so far:

1. First, there's the fact that you have to use MacOS to develop for the iPhone.  In my case, I'm borrowing my girlfriend's MacBook.  I would very much prefer to utilize my dual widescreen LCD monitors, but I realize that this complaint is circumstantial.  I'm sure that a savvy Mac user could navigate the MacOS with ease, but it's a struggle for me.  It would be nice if there were a Windows option somehow.

2. Second, I have to use XCode, Apple's free IDE.  I will be fair; for a free IDE, it's packed with decent features, and I can't really compare it to Visual Studio Express (another free IDE) given that the latter benefits from the features of the full versions of Visual Studio.  But it's still a giant step backwards.  The syntax highlighting is overly subtle, the code completion guesses at what you're trying to type but doesn't pop up a list of options (at least not automatically).  I've yet to see a list of method overloads appear; you're at the mercy of your memory and the greatly-inferior-to-MSDN documentation, which lists all of an object's methods/properties in one long list.  There doesn't appear to be any sort of refactoring capability, though I can probably blame the language (which I'll get to soon enough).  The solution explorer equivalent is strikingly un-Apple-like, showing redundant information while lacking important information at a glance.  I've run into bugs in which error and warning markers in the code don't disappear even after you fix the errors. (I even deleted the offending code entirely and rebuilt with no luck). 

3. Objective-C.  Oh my god.  Could Apple have picked a more obscure language?  Why not just stick to C or C++?  The syntax in objective C is unnecessarily arbitrary, with objects calling methods (or more specifically, "sending messages to call a method") of the syntax:

[object methodName]

(including the brackets.)  You can even (and are encouraged to) nest these calls, for optimal confusion:

[object1 methodName:[object2 getSomething:[object3:getSomethingElse]]]

My favorite (sarcasm, in case it wasn't obvious) detail about methods is the parameter passing.  You see, a method signature is defined not by its return type, name, and parameters, but rather just its return type and parameters.  Read that again: Return type and parameters.  Something missing?  That's right, there's NO METHOD NAME.  Or more specifically, the method name IS the parameter list!  So, a hypothetical method to open a file read-only might be:

[FileObject openFile:@"myfile.txt" readOnly:YES]

Or an even better example:

[MySpatialObject setPositionX:100 andY:120]

That's right, I can't have a method called "SetPosition".  Instead, the method is technically called: "setPositionX:andY".  Of course nobody would use the word "and" in a real-world parameter name, right?  GUESS AGAIN, it's encouraged!  Method names are supposed to read like prose.  I am a strong advocate of longer method/parameter names for the sake of readability and avoiding obscurity, but there are much better solutions to this problem than this.

And just as an extra kick in the nads, the standard coding conventions fly in the face of everything that modern, civilized software developers have evolved toward (e.g. curly braces on separate lines for the love of God, curly braces surrounding one-line if statements, non-cryptic class/variable names, etc.)

Oh, did I mention that this language isn't strongly typed?  Enjoy.

4. Interface Builder.  Fine, this relates to XCode, but it's bad enough to deserve its own category.  This is the GUI tool that creates...well, GUIs.  Hell, even Apple devs don't seem to like it.  It's again another ironic example of Apple's dev tools flying in the face of Apple's typical design philosophies.  This tool is completely unintuitive to use as opposed to Visual Studio's designers, involving all sorts of GUI elements that can be connected with lines as a way to graphically "wire up" events and relationships.  So much of what you'd expect (i.e. you click on a control in the visual designer and immediately see a context menu with this control's attributes and event wiring) just doesn't exist.  You have to dig through options to even see these things, and even when you find them, their function is not obvious.  Can the people who designed the iPhone interface please help out designing this tool as well?

---

There is much more to write about the iPhone dev woes but I'll save that for another post.  In general, if you want to know what the iPhone dev environment is like, use an iPhone for a week.  Then use a Windows Mobile phone the next week.  The extra pain you'll feel the second week is analogous to the pain you'll feel switching from the standard Visual Studio/C# environment to the iPhone's.  But at least in Windows Mobile's defense, it does have extra features it's trying to pack in.

 

After working on iPhone development/learning for a few hours today, I worked a bit on my XNA Game Studio project.  It was an almost orgasmic experience.  It felt like the feeling you get right after stepping off a treadmill after a long run.  Suddenly you feel like superman, almost gliding along the floor effortlessly when you walk.