Volume Number: 19 (2003)
Issue Number: 2
Column Tag: Getting Started

Digging in to Objective-C

by Dave Mark

In this month's column, we're going to start our foray into Objective-C. Before we do that, however, let's make sure we're on the same page, tools-wise.

If you haven't already, login to http://developer.apple.com/ and download the December 2002 Mac OS X Developer Tools. Note that the download is 301.2 MB so maybe let this one run during your lunch break. Note that the December 2002 Tools will only run on 10.2 or later. If you need to run on an earlier OS, stick with the April 2002 Tools.

Once your download is complete, you'll have a very large file named Dec2002DevToolsCD.dmg. Double-click this. The disk image that mounts will contain a file named Developer.mpkg. This master package will install all the packages in the Packages folder. No need to install these separately.

The install will take a while. Be patient. There's a lot of stuff here. Here's a list of the packages that will be installed as part of this process:

- Developer Tools (DevTools.pkg)

- Mac OS X SDK (DevSDK.pkg)

- Developer Documentation (DevDocumentation.pkg)

- Developer Examples (DevExamples.pkg)

- SDK pieces for UNIX development (BSDSDK.pkg)

- A package with extra pieces needed for Project Builder-emacs integration (Dec2002DevToolsExtras.pkg)

If your setup was the same as mine, you were running Project Builder 2.0.1 and are now running Project Builder 2.1. This is from the Project Builder 2.1 section in the file What's New.pdf:

- Support for external editors:

* You can use arbitrary editors for different file types.

* Project Builder will show you build errors in your external editor when you use BBEdit or emacs.

- Build system features:

* Project Builder will now do multiple compiles at the same time on machines with more than one processor.

* Project Builder's header dependency analysis is improved.

* Project Builder now links executables in a more optimal manner.

* You can now set compile flags on a per-file basis.

* Assembler flags are now separate from flags to the compiler.

- Interface to customize key bindings.

- Better CVS integration.

- The CodeWarrior project importer has been vastly improved.

- Miscellaneous interface improvements:

* You can now sort files, targets, and build phase objects in a project.

* You can display line numbers on the same line as your source.

* The breakpoint gutter has been improved.

- JavaDoc documentation is now indexed so that it can be used with Project Builder's integrated documentation.

- Improved text encoding support.

- There is support for dynamic C++ types in the debugger.

In addition, here's the non-Project Builder specific stuff:

* gcc3.1 has several bug fixes. In addition:

- an optimization has been made to speed up searching for header files. If your command lines have a lot of -I directives to add directories to the compiler's search path, this optimization should help your compile time.

- The HTML documentation for the compiler is missing from the release. You can find it on the web at:

http://developer.apple.com/techpubs/macosx/DeveloperTools/gcc3/gcc/index.html

http://developer.apple.com/techpubs/macosx/DeveloperTools/gcc3/cpp/index.html

* AppleScript Studio 1.2.1 adds enhanced dictionary support. The sample projects will now run on both Mac OS X 10.1 systems as well as Mac OS X 10.2. Please read the AppleScript Studio release notes for more information.

* CHUD 2.5.1 is now on the CD. CHUD is a set of tools for low-level system debugging and profiling. To install, open the disk image, and follow the instructions.

* !AppleScript Editor 2.0 Beta is now available in the Pre-release Software folder. Please read the "About These Packages.rtf" file in the Pre-release Software folder for more details. Note that this package requires Mac OS X 10.2.3 or higher.

* The jikes Java compiler has been updated to version 1.17.

* PackageMaker has some new features:

- Drag-and-drop functionality in the list editor.

- Inline attribute editing.

- Progress sheet for status during package creation.

- Package completion dialog.

* Sherlock SDK - There is now an SDK available to develop your own Sherlock channels. See

/Developer/Examples/Sherlock for sample channels and the online documentation for more information.

* DiscRecording SDK - There are now sample projects demonstrating the DiscRecording framework. Please see: /Developer/Examples/DiscRecording/About Disc Recording Examples.rtf for more information.

* CoreAudio SDK - There are more examples in /Developer/Examples/CoreAudio. Please see /Developer/Examples/CoreAudio/ReadMe.rtf for more information.

* FireWire SDK - There is now a complete SDK for developing for FireWire devices. Please see

/Developer/Examples/IOKit/firewire for the samples.

* ForceFeedback SDK - The header files necessary to take advantage of Mac OS X 10.2.3's ForceFeedback framework have been added.

* AvailabilityMacros - You can now control which OS version you want to target your application for using the AvailabilityMacros. Please see

/Developer/Documentation/ReleaseNotes/AvailabilityMacros.h for more details.

* New and updated documentation. Lots of new documentation content is included in this release. Please check the various "what's new" portions of the documentation for more information.

When you launch Project Builder 2.1 for the first time, the release notes window appears. You can bring this window up again at any time by selecting Show Release Notes from Project Builder's Help menu.

OK. Now that we're all using the same tools, let's dig into our main course. Objective-C is based on the C programming language. In effect, it is C with objects. Though there are many differences between Objective-C and C++, the main difference lies in the dynamic nature of Objective-C.

C++ requires static dispatch, static typing, and static loading. Objective-C offers dynamic dispatch, dynamic typing, and dynamic loading. In a nutshell, static dispatch means the decision of which object receives which message happens at compile-time, while dynamic dispatch means the decision is delayed until run-time.

Same thing with typing and loading. When the type of the message receiver can be determined at run-time, that's dynamic typing. When code can be linked and executed at run-time as opposed to at compile-time, that's dynamic loading.

To me, all three of these concepts are very tightly intertwined. A static approach offers the safety of forcing a lot of problems to the surface at compile-time. Don't be lulled into a false sense of security, however. Just because your code compiles doesn't mean your code isn't riddled with errors. It just means that your code conforms, at a basic level, to the language syntax enforced by the compiler. But static typing, for example, clearly offers a certain level of safety not afforded by dynamic typing.

The dynamic approach jettisons the static safety net in exchange for incredible flexibility and freedom. Dynamic loading means you can deliver a new suite of objects to your customer over the net, and have the code installed, all while the existing app is still up and running. Imagine the possibilities. You could fix a bug on a mission-critical program without having to shut it down. If you knew the protocol, you could even patch someone else's program, replacing their inferior object with one of your own design.

To be fair to C++, there is a certain element of risk in a completely dynamic approach. But with this risk comes great potential reward. Whichever side of the dynamic/static argument you come down on, there is no downside to learning and understanding Objective-C. If you understand the benefits of Objective-C, you can make an informed choice between it and C++. And the cool thing is, with Objective-C, you can still use static typing when you choose to (to make an element of your code clearer to others, for example). With Objective-C, you get the best of both worlds.

If all this seems a little vague, not to worry. Over time, as we dig into more and more code, these concepts will fall into place. Let's take a look at an example.

To start things off, here's a relatively simple C++ program (lifted and slightly modified from Learn C++ on the Macintosh, with permission from the author!) that we'll translate into Objective-C. We're going to define a class named Employee, then create and destroy a couple of Employee instances.

Want to follow along in Project Builder? Create a new project, and select "C++ Tool" from the "Tool" category when prompted for the type of project to build. Now select New File from the File menu and choose "C++ Class" from the "Carbon" category. You'll call the new class "Employee". Project Builder will create two new files (assuming you checked the "Also create Employee.h" checkbox) and add them to your project. All you need to do is replace the contents of Employee.h, Employee.cpp, and main.cpp with the code below.

Got a net connection? Rather download the code than type it in? We're working on adding the code downloads to the MacTech web site. If that is not up and running by the time you read this, head over to http://www.spiderworks.com and download the code from there. I'll put both the C++ and Objective-C versions up for your downloading pleasure.

Here's Employee.h:

class Employee
{
//         Data members...
   private:
      char   employeeName[ 20 ];
      long   employeeID;
      float   employeeSalary;
//         Member functions...
   public:
            Employee( char *name, long id, float salary );
            ~Employee( void );
      void   PrintEmployee( void );
};

Here's Employee.cpp:

#include <iostream>
#include "employee.h"
Employee::Employee( char *name, long id, float salary )
{
    strcpy( this->employeeName, name );
    this->employeeID = id;
    this->employeeSalary = salary;
    
    std::cout << "Creating employee #"
                           << employeeID << "\n";
}
Employee::~Employee( void )
{
    std::cout << "Deleting employee #"
                           << employeeID << "\n";
}
void   Employee::PrintEmployee( void )
{
    std::cout << "-----\n";
    std::cout << "Name:   " << employeeName << "\n";
    std::cout << "ID:     " << employeeID << "\n";
    std::cout << "Salary: " << employeeSalary << "\n";
    std::cout << "-----\n";
}

Finally, here's main.cpp:

#include <iostream>
#include "employee.h"
int main (int argc, const char * argv[])
{
    Employee   employee1( "Frank Zappa", 1, 200.0 );
    Employee   employee2( "Donald Fagen", 2, 300.0 );
    employee1.PrintEmployee();
    employee2.PrintEmployee();
}

Once all the code is typed in, give it a run and compare your results to those shown in Figure 1. If you compare the results with the code in main.cpp, you'll see that the first two lines are produced as the two Employee objects are created, the next two chunks (5 lines each) are produced by the two calls to PrintEmployee(), and the two "Deleting" lines are produced when the program exits and the objects are destroyed.

The Employee object is fairly straight-forward. Looking at the code in Employee.cpp, you'll see that the constructor uses its arguments to initialize the data members of the Employee object, then uses cout to send a message letting us know the object is being created. The destructor also uses cout to let us know its object is being destroyed. And PrintEmployee() uses cout to print some useful info as well.

Pretty straight-forward, right? Now let's create an Objective-C program to do the same thing.

In Project Builder, select New Project... from the File menu. This time, select "Foundation Tool" from the Tool category. Now select New File... from the File menu and choose Objective-C Class from the Cocoa category. Name the new file Employee.m and be sure the "Also create Employee.h" checkbox is checked.

As you did with your C++ project, now you'll replace the contents of Employee.h, Employee.m, and main.m with the code below. Here's Employee.h:

#import <Foundation/Foundation.h>
@interface Employee : NSObject {
    @private
        char      employeeName[20];
        long      employeeID;
        float      employeeSalary;
}
- (id)initWithName:(char *)name andID:(long)id
    andSalary:(float)salary;
- (void)PrintEmployee;
- (void)dealloc;
@end

Here's Employee.m:

#import "Employee.h"
@implementation Employee
    - (id)initWithName:(char *)name andID:(long)id
                            andSalary:(float)salary {
        strcpy( employeeName, name );
        employeeID = id;
        employeeSalary = salary;
        
        printf( "Creating employee #%ld\n", employeeID );
        
        return self;
    }
    
    - (void)PrintEmployee {
        printf( "----\n" );
        printf( "Name:   %s\n", employeeName );
        printf( "ID:     %ld\n", employeeID );
        printf( "Salary: %5.2f\n", employeeSalary );
        printf( "----\n" );
    }
    - (void)dealloc {
        
        printf( "Deleting employee #%ld\n", employeeID );
        
        [super dealloc];
    }
@end

and here's main.m:

#import <Foundation/Foundation.h>
#import "Employee.h"
int main (int argc, const char * argv[]) {
    NSAutoreleasePool * pool =
                        [[NSAutoreleasePool alloc] init];
    Employee*   employee1 = [[Employee alloc] initWithName:"Frank Zappa" andID:1 andSalary:200];
    Employee*   employee2 = [[Employee alloc] initWithName:"Donald Fagen" andID:2 andSalary:300];
    [employee1 PrintEmployee];
    [employee2 PrintEmployee];
    
    [employee1 release];
    [employee2 release];
    
    [pool release];
    return 0;
}

As you did before, run the project. This time, compare your results with Figure 2. Look familiar? The Salary field looks a bit different but, other than that, the results are identical.

Take some time and look at the Objective-C and C++ code side-by-side. You should be able to tell a lot about the Objective-C code just from this context. In next month's column, we're going to dissect the Objective-C code, line-by-line. Till then, here's some food for thought:

In C++ you call a member function. In Objective-C you send a message to a receiver. For example, in C++ you might use an object pointer to say:

myObj->changeValue;

In Objective-C you'd say:

[myObj changeValue];

Objective-C classes are, like their C++ counterparts, broken into an interface (the ".h" file) and an implementation (the ".m" file). Instance methods start with a "-" character in the interface, class methods start with a "+".The type "id" is Objective C's generic object pointer type. You'll see it a lot.

(id)myFunc; declares a function named myFunc that returns an id pointer.

(id)getP:(int)p; declares a function named getP: that takes a parameter p of type int. The colon at the end of the function name indicates that the function takes a parameter.

(id)getP:(int)p andQ:(long)q declares a function named getP:andQ: taking two params - an int named p and a long named q.

Look through the code, think about what's happening, see you back here next month...

Dave Mark is very old. He's been hanging around with Apple since before there was electricity and has written a number of books on Macintosh development, including Learn C on the Macintosh, Learn C++ on the Macintosh, and The Macintosh Programming Primer series. Check out Dave's web site at http://www.spiderworks.com