macOS Learning Objective C question (Bit Operations?)

[GorillaPaws]

Hey guys. A while back I got the O'Reilly book and worked through the first few chapters, but got busy with school and and a little discouraged (especially because the bood was already outdated by xcode's updates by then) so I stopped. Then the Trent and McCormack book came out and it renewed my interest in learning Cocoa, so I hit the threads here and saw that I really ought to check out the books by Kochan and by Hillegass.
So, I decided to get all 3 and really do it this time. I've been reading Kochan's book first (which is so much better than the O'Reilly one), and got half-way through chapter 4, and then they started getting into Bit Operations. And I must admit I got scurrrred. See, I'm dyslexic, and my brain has trouble with computational tasks, but is great at grasping conceptual ones. So when Kochan started talking about right shifting hexadecimals, I got nervous.
Now I get the concept behind non-base ten numbers, but I'm not sure how/have no experience in converting between them. Furthermore, I know that everything on a computer is converted into binary, but I don't understand the process. I always assumed it was the machine level code/kernel that deals with all of this, but it appears that this is handled by the programmer as well.
My questions are: To what extent is Cocoa programming involved with bit level operations? Is this something that is used frequently, and I should stop the Kochan book until I fully understand this process? or is it something that Cocoa programmers have access to but rarely utilize? or something that is utilized frequently in developing certain types of applications (if so which types), but not in most others? I'm gonna keep going on in the book and see how I do, but I appreciate any clarification you can bring to my back-***wards brain Thanks.

 

[robbieduncan]

Cocoa has no effect on the way that bit shifts are dealt with. It's the same as standard C (which if you don't know you should go and learn as you'll need it).

99% of Cocoa programs don't need to bit shift anything and don't need you to know anything about binary representations so I'd just skip on to the next section.

 

[caveman_uk]

They're used a lot less often in Objective-C/Cocoa than they are in straight C. I've used & and | here and there - usually when you have to use a carbon function. I can't recall ever using the bitwise shift operators.

 

[GorillaPaws]

Thanks for the quick response guys (or should I say mates?). I feel a lot better knowing I won't have to deal with that stuff.

 

[HiRez]

The one place I use bit-shifting quite a bit in Cocoa is when doing operations on color components in raw image pixel data. Other than that, not so much. And even there, Cocoa now has some methods you can use for that to avoid low-level bit ops, like [NSBitmapImageRep colorAtX:y:].

 

[superbovine]

here is an example in one of my projects. this code is old btw... very old and still is used.

      switch (GET_POS(ch)) {
         case POSITION_SLEEPING:
            gain += (gain>>1); /* Divide by 2 */
            break;
         case POSITION_RESTING:
            gain+= (gain>>2);  /* Divide by 4 */
            break;
         case POSITION_SITTING:
            gain += (gain>>3); /* Divide by 8 */
            break;
      }

 

[GorillaPaws]

Organization in Cocoa apps?

Again, thanks for all of your responses. I have another question now, and I figured I'd post it here instead of starting a new thread. My confusion has mainly to do with the typical organization of a cocoa application in terms of the main.m, and the whatever.m and whatever.h files. I've taken a quick break from the Kochan book, (I've gotten though most of the basic stuff already--and I have to say once again that it's VERY well written) and started reading Hillegass one, to start building some apps.

I realized that the structure of the apps seems different, and I'm a little confused. You have the whatever.h file which is your @interface section of your program. This is like an abstract to a lab report, right? Basically, you declare all of any classes you will use and from which parent class they derive. Then you specify which instance variables will be associated with that class, followed by which methods you will use with that class and what type of data they return (void, id, double etc). Good so far?

Next you have your @implementation file which is your whatever.m file. This section lays out what exactly each method does (i.e. how it works), right?

Finally you have your main.m file which is where you allocate/instantiate your objects and run your methods on them. This is the bulk of where your program is doing things, Right? At least this is how Kochan has set up her programs in Objective-C. I like this layout because everything is logically and rationally organized. You can see where each element is, and how it's supposed to interact with everything else.

Now when I started working through Hillegass' book. We were using the Interface Builder to do a lot of the things that I would have had to code by hand (like allocating and instatiating objects for example). I'm not seeing alot of the code that should be there (e.g. where is the code that allocates/instatiates all of my button/textfield objects? what about the window of my app itself isn't that an instance of an NSWindow (or NSWindowView)? where is the code to do all of this stuff in my program? It seems like NSApplicationMain in my main.m file is doing a whole lot here that I'm not seeing. And the only coding I'm doing is in the whatever.m file. And a little in the whatever.h files. What am I not getting?

 

[logicat2001]

...I have another question now, and I figured I'd post it here instead of starting a new thread

I'd consider starting a new thread, as this new question has nothing to do with bit operations; it'll be much easier for the next person who's looking for answers to find these.

the whatever.h file...is your...abstract...of any classes you will use and from which parent class they derive...you specify...instance variables...followed by...methods...and what type of data they return

That's a nice summary and, just to be sure, you don't need to abstract any class that you're going to use, only the classes you create yourself (or alter, e.g. by subclassing or using categories). You can use plenty of classes in your app and never need to write a .h file for it. When you #import <Cocoa/Cocoa.h> you make all the Cocoa framework's classes available for your app, without duplicating or writing new .h/.m files.

your @implementation file...lays out what exactly each method does (i.e. how it works)

Yup.

your main.m...is where you allocate/instantiate your objects and run your methods on them. This is the bulk of where your program is doing things, Right? At least this is how Kochan has set up her programs in Objective-C.

Well, you can do things in any number of ways. Most Cocoa tutorials use main.m solely to return an instance of NSApplication. This is the default if you start a project in XCode and use any of the Cocoa templates.

A tip: download AppKiDo and get familiar with it. It's indispensable when I'm coding. While you're at it, also grab Accessorizer. Both apps are available for free (and Accessorizer accepts donations.) They are absolutely fantastic, and are always running whenever I code.

Check out the Apple documentation for NSApplication (either via XCode's documentation, or AppKiDo, etc.). Here's what you'll find:

The NSApplication class provides the central framework for your application’s execution. Every application must have exactly one instance of NSApplication (or a subclass of NSApplication). Your program’s main() function should create this instance by invoking the sharedApplication class method. After creating the NSApplication object, the main() function should load your application’s main nib file and then start the event loop by sending the NSApplication object a run message. If you create an Application project in Xcode, this main() function is created for you. The main() function Xcode creates begins by calling a function named NSApplicationMain(), which is functionally similar to the following:

void NSApplicationMain(int argc, char *argv[]) {
[NSApplication sharedApplication];
[NSBundle loadNibNamed"myMain" owner:app];
[NSApp run];
}

I like this layout because everything is logically and rationally organized.

That's cool. You're free to work as you are most comfortable. IMHO, that's why different tutorial writers end up with different ways of structuring their apps.

working through Hillegass' book...I'm not seeing alot of the code that should be there (e.g. where is the code that allocates/instatiates all of my button/textfield objects? what about the window of my app itself isn't that an instance of an NSWindow (or NSWindowView)? where is the code to do all of this stuff in my program? It seems like NSApplicationMain in my main.m file is doing a whole lot here that I'm not seeing

Ah, yes, the beauty of the .nib file. One of the coolest things about using IB is that the resulting .nib isn't a template that is used to "create" your user interface. It's actually an encoded version of all the objects in your interface. The nib file is the code, and you (often) don't have to worry about how that GUI is programatically generated. You are free to create all of it by hand, if you wish (for example, as penance for all the bad things you've done in your life), but you often don't have to.

How or why would this be a "better" way? One of the wonderful things about Cocoa is the inherent elegance of it all. If you're going to use AppKit and Foundation, I'd strongly encourage you to learn what it was designed to spare you, the programmer, from doing manually. (It's almost like a piano player practicing their scales.) After you've learned what's there, feel free to break away and improvise all you want; if you wish to get down to the nitty-gritty code, you'll be able to use that stuff in your Cocoa apps without jumping through hoops of fire.

In the Cocoa world, you'll often find that the main.m code is the single call to NSApplicationMain(), while the functional engine of the app is implemented (in the simplest case) by a Controller class from XCode + a GUI from InterfaceBuilder. By moving the conditional/unique aspects of your code into a custom controller, you reap the benefits of having the core code of your app be a subclass of NSObject. You get all the OOP goodies you could ever want, plus things like Delegate, Notifications, Outlets, etc.

I think you should keep going, whether or not you choose to focus on main.m or not. Eventually, you'll get a greater understanding of the what's and why's involved, and it'll make you a better coder in the end.

For the record, your comments about main.m vs. IB-based code is one of the best I've come across recently. I have no doubt that you've got what it takes. You're asking great questions right from the get-go.

Best,
Logicat

 

[GorillaPaws]

Thanks Logicat, I appreciate the encouragment! I kinda figured something like that was going on w/ the nib file & NSApplicationMain thing, but you can imagine how shocking it was at first. Yeah... I definitly should have started a new thread with this one, but I didn't want to plaster the Mac Programming forum with all of my noob questions . I'm sure I'll learn to appreciate all of the time and energy that IB saves me, but when I'm learning, its nice to be able to see how everything fits together.

I've already (mentally) planned out my first application, and I'm pretty excited about building something "original" (not that my idea is all that original, but it won't be from a tutorial at least). The general idea is to create a small app that will be kind of similar to apple's converter widget. It will have a drop-down menu at the top and you will be able to select 1 of many different standard formulas (e.g. the quadratic formula, the gravity formula, the acceleration formula etc.), and the window will change to accomodate that particular formula's nuances. I.e. it will display the quadratic formula at the top, with 3 text boxes, corresponding to the 3 variables in the formula. The beauty of an app like this is that it's easily scaleable for a beginer (I can start off by only making it for one formula) and expand it as I learn how to do more.

Eventually, I'd like to learn how to turn it into a widget, getting help from anyone who wishes to. (especially with the graphics end of things (I have NO clue what's going on w/ any of that). But I'm getting ahead of myself, I'm gonna work though all of my books first. I'll keep everyone posted, and I'll probably ask many more questions. (This time in a new thread, I promise).

 

[logicat2001]

I've already (mentally) planned out my first application, and I'm pretty excited about building something "original" (not that my idea is all that original, but it won't be from a tutorial at least). The general idea is to create a small app that will be kind of similar to apple's converter widget. It will have a drop-down menu at the top and you will be able to select 1 of many different standard formulas (e.g. the quadratic formula, the gravity formula, the acceleration formula etc.), and the window will change to accomodate that particular formula's nuances. I.e. it will display the quadratic formula at the top, with 3 text boxes, corresponding to the 3 variables in the formula.

As an example of some of what Cocoa is able to accomplish, you can do this using Cocoa bindings, and a NSValueTransformer sub-class, without almost any other code. The code you'd have to implement is the custom translator portion, i.e. the actual mathematical conversions. Otherwise, all the "code" that would be required to keep the GUI and data in synch is available via drop down menus in IB.

Best,
logicat