Objective-C: the More Flexible C++

An introduction to Objective-C for programmers familiar with C++ or any other OOP language.

The only way to tell an object to do something is to send it a message. The well known metaphor of objects as active actors can be used. An actor communicates through a message to another to request that she do something. The receiving object is called the "receiver" of that message. The receiver will determine the concrete behavior. It will make a big difference if you send "I love you" to Catherine instead of Katia. Different receivers cause different implementations.

[receiver message];
[receiver message: arg1];

Arguments are used after colon-terminated message selectors.

If a message is declared as -message, it can be sent to objects. A leading plus sign (+) means that the message can be sent to class objects. The default return type for methods is "id". If a method has nothing useful to return, it returns "self", which is a pointer to the object to which the message was sent (similar to "this" in C++).

By implementing the method -doesNotUnderstand:

-doesNotUnderstand: msg { [msg sentTo:delegate]; }

an object can forward messages to another object ("delegate"), including messages that return C structs, doubles, chars and so on.

Classes and Inheritance

A class is used to produce similar objects, called instances of the class. Classes are used to encapsulate data and methods that belong together. Methods are the operations that Objective-C applies to data and are identified by their message selectors.

Objective-C supports polymorphism: several classes can have a method with the same name.

Inheritance is used for code reuse. Classes inherit variables and methods from a higher-level class called a super-class. A class that inherits some or all of the methods and variables is a sub-class. In Objective-C, all classes are a sub-class of a primal super-class called Object.


Compile-time and link-time constraints are limiting because they force issues to be decided from information found in the programmer's source code, rather than from information obtained by the running program. Such static languages usually refuse to introduce new modules or new types during runtime. Objective-C makes as many decisions as possible at runtime:

  • Dynamic typing: waiting until runtime to determine the class of an object.

  • Dynamic binding: determining at runtime what method to invoke--no need to bother about what is done when. This allows it to change the components of a program incrementally.

  • Dynamic loading: program segments are not loaded into memory until they are actually used, thereby minimizing the system resources required for an instance of a program.

If your program offers a framework for others to use at runtime, you can discover what they have implemented and load it at runtime as needed.

Objective-C programs are structured through inheritance (how objects relate by type) and the pattern of message passing (explains how program works).


As the name implies, object-oriented programs are built around objects. Objects are the root of the Objective-C family tree.

id is an object identifier that is a distinct data type. It is a pointer to an object (in reality a pointer to an object's data--its instance variables). The actual class of the Object does not matter because Objective-C does runtime binding.

nil is the null object. The id of nil is 0. Other basic types of Objective-C are defined in the header file, objc/Objc.h.

Every object also carries an is an instance variable that identifies the object's class (what kind of object is it?). This allows objects to be typed dynamically at runtime. isa also allows objects to introspect themselves so they can find out what methods they have.

Usually, you create objects with a call to alloc:

id MyRect;
myRect=[Rectangle alloc];

alloc allocates and clears memory for the instance variable. Initialization typically follows allocation immediately.

myRect=[[Rectangle alloc] init];

Here is an extended example of the lists.

#import <objc/Object.h> 
@interface List : Object 
  int list[100];          // These are instance variables.
  int size;
/* Public methods */
- free;
- (int) addEntry: (int) num;
- print; 
#import "List.h" 
@implementation List 
+ new   
  self = [super new];
  [self resetSize];
  return self;
- free
  return [super free];
- (int) addEntry: (int) num
  if (size<100)
    list[size++] = num;
  return size;
- print
  int i;   
  printf("         \n");
  for (i = 0; i < size; ++i)
    printf ("%i ", list[i]);
  return self;                // Always return self
                              // if nothing else makes sense.
- resetSize
  size = 0;
  return self;

List2.h, below, inherits from the above Lists. -doesNotRecognize is the standard method that gets called if a class does not have the required method. magicMethod in main.m does not exist so doesNotRecognize gets called. This allows for an easy way to create Delegatorpatterns or to use Proxy-setups.

#import <objc/Object.h> 
#import "List.h"
@interface List2 : List  // List2 is a subclass of List
- free;
- (int) sum;
- doesNotRecognize: msg;
#import "List2.h"
#import "List.h"
@implementation List2 : List
- (int) sum
  int i=0;
  int sum=0;
  for (i=0; i<size; i++) 
  return sum;
-doesNotRecognize: msg
    printf("no clue!\n");
    return self;
import <objc/Object.h>
#import "List.h"         
#import "List2.h"
main(int argc, char** argv, char** env)
  int i;
  id list, list2;        // id is a general data type for objects.   
  list = [List new];     // create an instance of class List.
  [list addEntry: 5];    // send a message to the object list
  [list addEntry: 3];
  [list print];
  [list free];           // get rid of object
  list2 = [List2 new];
  [list2 addEntry: 6];
  [list2 addEntry: 4];
  printf("\nsum: %d\n",[list2 sum]);
  [list2 magicMethod];


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

This thread is awesome.

Anonymous's picture

I love open threads. Look at this below - beautiful. Spanning from 2002 to 2010, there is a gradient of acceptance and spite which spans the birth and explosion of the iPhone. Surprisingly, the questioning of retroactive political correctness (c.2003) got the most attention.
I'd like to learn Objective-C. But I have better things to do, and a heap of legacy Java code. I just "learned" J2ME, which is a dung heap basically built for the "halcyon" monochrome days of Nokia. Smartphones are the future. Too bad Apple is cock-blocking Java, although I have to say in the last 8 years Java has been bastardized beyond recognition (FX, packages, J2ME etc.). Perhaps in part due to the question: how could Java defend itself while not generating any direct revenue?
We'll see about Objective C, and whatever Objective C++. Seems like the iPhone is the biggest player there. Who ever thought that C++ was the end-all, be all of languages? I guess I did.

Maybe more flexible, but definately not productivity.

Anonymous's picture

Objective-C, maybe more flexible (still arguable) OOP than C++,
but definately not for it Productivity using this language.
(length of the code, readability, maintenance, etc)

For eg, below is the code required just to get a date-time data from an index on array of DateTime in Obj-C, in IPhone Cocoa Platform.

// <<<<<<<<<<<<< start of code section >>>>>>>>>>>>>>>>>>

NSDateFormatter *df = [[NSDateFormatter alloc] init];
[df setDateFormat:@"EEE, dd MMM yyyy HH:mm:ss ZZ"];
NSLocale *local = [[NSLocale alloc] initWithLocaleIdentifier:@"en_US"];
[df setLocale:local];
NSDate *theDate = [df dateFromString:[rssData[m_selectedGroupIndex].pubDate objectAtIndex:m_selectedArticleIndex]];

int month,year, day, weekday, hour, minute, sec;

[df setDateFormat:@"yyyy"];
year = [[df stringFromDate:theDate] intValue];

[df setDateFormat:@"MM"];
month = [[df stringFromDate:theDate] intValue];

[df setDateFormat:@"dd"];
day = [[df stringFromDate:theDate] intValue];

[df setDateFormat:@"c"];
weekday = [[df stringFromDate:theDate] intValue];

[df setDateFormat:@"H"];
hour = [[df stringFromDate:theDate] intValue];

[df setDateFormat:@"m"];
minute = [[df stringFromDate:theDate] intValue];

[df setDateFormat:@"s"];
sec = [[df stringFromDate:theDate] intValue];

// do something....
[df release]; // must, otherwise program crash.
[local release]; // must, otherwise program crash.

// <<<<<<<<<<<<< end of code section >>>>>>>>>>>>>>>>>>

This definately is NOT the shortest code among the OOP variant (C++/Java/C#/Obj-C).

Another major problem with Obj-C is it memory management, it is not purely programmer skill that can decided, but the way the object handling the memory in some sort like 'black-box' is a big problem,
for eg, when can free the object ? there is only a method called 'retainCount', but even these, it is not working, offical state that stated so in the document. This forced the developer to implement own obj state - and this increase the code needed and is more error prone and reduce productivity, if the object forget to free, the app will crash. There is no constructor and destructor as in C++ and JAVA, and it is not possible to support something like


MyClass *obj1 = new MyClass("Hello");
// Obj-C:
// [MyClass *obj1 = [[MyClass alloc] initWithFormat:@"%@",@"Hello"];

... do something on myclass

delete obj1; // obj-c : [obj1 release]

obj1 = NULL; // this not work in Obj-C, cause you are sending a NULL message to obj1, not re-assign the pointer, telling other that obj1 instance is no more exist/valid.

.... do something

// end of the program, doing cleanup.
if (obj1) // This not work in Obj-C
delete obj1;

// Obj-C version:
// Ideally, work is way, but it is NOT, never rely on retainCount, not work, officially state in the official docs.
if ([obj1 retainCount] > 0])
[obj1 release];


Obj-C have exist for some time, not a new lang, but until now, the memory handling problem is still exist, nothing have been improved, nothing have been done to correct the 'retainCount' defect.

Alhtough there is now Obj-C++, but not available on IPhone platform, not a good news for those who want to be developer for IPhone.

programmer should focus as much as possible on logic/biz logic, not too much on handling simple memory allocaiton and deallocation and state
(of-course, not to abuse memory used and not for case like linked-list, binary-tree kind of code, that is unavoidable, but here is just a very basic memory management case).

Obj-C memory handling definately add up very much time on the development time and resource.

About Java, one of problem is the code cannot divide into separate file. (whereas all other C++ variant can, include C#).
Sun say reason behind it, but the real reason is that their architect problem/limitation, which, to rectify now is not much possible due to compatible with older program issue.

About Apple blocking Java and Flash:

1. Apple force developer using their XCode to develop App on their IPhone, for the reason ther can then generate revenue on Mac machine sale and XCode license, annual subscribtion fee.

Many not realize that IPhone SDK is run on Apple Machine only, not Windows, neither Linux, for the fact that 99% of the programmer is using Windows (mostly) and/or Linux (smaller part). So you need to buy the macine from Apple, just for developing IPhone App.
(Apple NOT EVEN mention supported platfrom on their SDK download, many innocent developer even not realized this after find some 'hard' way to successfully download the huge 2.4GB + SDK).

2. Apple block Flash revealed at last - to facitate their own Ad network - iAdd.

(I have develop in C/C++ for some time, not as long as Bill Gate and Steve Jobs, however, already > 15 Years in various platform, dated back since Commodore Amiga day, using AimgaBasic in 1988 since I'm still in secondary-school, playing EA game like F-18 Interceptor. I have writeen many Windowsce commercial, fat/thick-client application. Last year I wrote a local News App for a customer in Obj-C, and it ranked #1 in that category. I cannot disclose the App name, due to Non-disclose-Agreement with Apple, and comment non on favor on apple will make your app disappear on it App-Store. And my conclusion on comparing this these 2 platform and language is - Apple should use C++ for it SDK platform, not Obj-C, for programmer productivity and reliable App (not easy crash) reason.)


Now let's rewrite that cleanly

Ivan Vučica's picture

I'm not an expert in ObjC (only having a few months of experience) and I never used date formatter class. Even I managed to see that you're wrongly blaming the language.

1. Use categories. You know that you'll be getting 10 integers with various formats from a date? Well, extend that NSDateFormatter class and add a function for grabbing the appropriate think.
2. You may even want to define k-onstants for various formats to improve readability. (I didn't do that.)
3. Use that autorelease pool. It's there for a reason, and Apple uses it extensively in their code. Autorelease pool exists in the mainloop and gets automatically flushed whenever your code returns to the mainloop. You can declare extra pools if you need them. See main.m in the templates; you can see an autorelease pool declared there since Apple APIs use it so extensively. (I declared one in my main(), below.)

Here's a full program and a Makefile. I'm even fairly certain it should work under GNUStep on Linux. (Although I didn't test, and I think categories might be a 2.0 addition that most of the articles I read claim to be unsupported with GNUStep.)

<<<<<<<<<<<<< objcdate.m >>>>>>>>>>>>>>>>>>>>>


@interface NSDateFormatter(withIntVal)
-(int)intWithDate:(NSDate*)date format:(NSString*)format;
@implementation NSDateFormatter(withIntVal)
-(int)intWithDate:(NSDate*)date format:(NSString*)format
[self setDateFormat:format];
return [[self stringFromDate:date] intValue];

void testDateFromRSSString(NSString* dateString)
NSDateFormatter *df = [[[NSDateFormatter alloc] init] autorelease];
[df setDateFormat:@"EEE, dd MMM yyyy HH:mm:ss ZZ"];
NSLocale *loc = [[[NSLocale alloc] initWithLocaleIdentifier:@"en_US"] autorelease];
[df setLocale:loc];
NSDate *date = [df dateFromString:dateString]; // already autoreleased

int year = [df intWithDate:date format:@"yyyy"];
int month = [df intWithDate:date format:@"MM"];
int day = [df intWithDate:date format:@"dd"];
int weekday = [df intWithDate:date format:@"c"];
int hour = [df intWithDate:date format:@"H"];
int minute = [df intWithDate:date format:@"m"];
int sec = [df intWithDate:date format:@"s"];

printf("Input: %s\n", dateString.UTF8String);
printf("Year: %d Month: %d Day: %d Weekday: %d Hour: %d Minute: %d Sec: %d\n", year, month, day, weekday, hour, minute, sec);

int main()
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

testDateFromRSSString(@"Tue, 09 Mar 2010 00:01:02 +0100");

[pool release];
return 0;

<<<<<<<<<<<<<<<<<<< end objcdate.m >>>>>>>>>>>>>>>>>>

And the makefile:

<<<<<<<<<<<<<<<<< Makefile >>>>>>>>>>>>>>>>>>>>>>

all: objcdate.m
gcc -x objective-c -framework Foundation objcdate.m -o objcdate

<<<<<<<<<<<<<<<<< end Makefile >>>>>>>>>>>>>>>>>

Now, wasn't that shorter and simpler?

The reason code crashes is due to programmer's carelessness. When refcounting is included in the API itself (practically in the language itself), yet the programmer retains fine control over it, then the places where the program can crash is much reduced. Along with smart behavior when it comes to null pointers being passed as "self" into functions, my ObjC code gets written much faster than it was when I wrote C++ code.

You say ObjC memory management adds to development time. Sure it does, since you obviously don't use autorelease. Having autorelease pool flushed at a sensible place like the main event loop means I can return an object with my mind at ease, knowing that whoever grabs it has a duty to retain it, or else it'll get flushed when the code goes back into the mainloop. And most of the time, the object does indeed get flushed very soon. But my mind is at ease, since whoever got the object can still retain it. Refcounting is magical, without hiding itself as with garbage collectors!

C++ cannot easily get refcounting implemented at such a low level. ObjC trains you to refcount properly!

You say that [obj1 release] does not work. It does, if you consistently use retain, release and autorelease according to specs. I never had a problem where it wasn't a human error, and I never had to use [obj1 retainCount] except while debugging.

Finally, I tried out Flash Builder in CS5. What it produced sucks horribly. I have a single bitmap image scaling and fading out with alpha blending over the course of 25 frames. I estimate I'm getting 6-7 FPS on an iPhone 2G. That's unacceptable; this is a single image over a black background. Deploying an app takes a minimum of 1m20s. That's not counting that you still didn't transfer the produced .ipa to the device. Flash on iPhone sucks.

My biggest problems with Cocoa and Objective-C are:
- Apple did not continue producing YellowBox (Cocoa for Windows)
- Cocotron is a third party implementation of Cocoa for Windows and still works unreliably (be prepared to fix the framework and submit the patches back to Cocotron's most amazing developers)
- GNUStep people are not trying to implement Cocoa, they are trying to implement OpenSTEP, meaning I cannot count on porting to GNUStep to be an easy endeavor as soon as I step away from Foundation frameworks. Maybe this will change, or has changed since most of the docs I read were written.

Cocoa does have a few gaping holes and so does Objective-C, but your article and code demonstrate none of those.

What you are primarily

Anonymous's picture

What you are primarily attacking is an SDK. The primary language is the implementation of the compiler, not the libraries the compiler considers to be standard. Attacking a language based on its standard library is a ridiculous thing to do. If you have such an issue with the SDK I recommend you create a "wrapper" for it. By the way, your code looks ridiculously overcomplicated for providing the date.

(Apple NOT EVEN mention supported platfrom on their SDK download, many innocent developer even not realized this after find some 'hard' way to successfully download the huge 2.4GB + SDK).
If the developer in question isn't smart enough to know this, they're not smart enough to program for it. And what is this 'hard' way you speak of? Sounds like something illegal, making the developer not-so innocent.

when can free the object ?
Try something along the lines of [myobject release]; There are also auto-release pools that allow for the object to be released when the pool is released. This simplifies programming to an extent.

Obj-C memory handling definately add up very much time on the development time and resource.
Provide a solid example of this. Objects are allocated quite easily.

MyObject *pObj = [[MyObject alloc] init];

/* do stuff with the object */

[pObj release];

Apple blocked Java and Flash to keep other developers from executing code that Apple can't validate themselves. Although this was probably intentional to make Apple money, it also adds a security feature to the iPhone. The user can't get any app that hasn't been validated (unless they jailbreak their phone) and therefore can't get any sort of a virus unless they go out of their way, in theory. (In practice, this may be different.)

The number of years you've been programming provides no merit by the way. Your ability to program does and solve problems does. I'm not attacking you, but showing why your statement is irrelevant. Programming for years measures up only to as much quality as you've programmed and how far you've expanded, in my opinion.

Your English does not appear to be well structured. Normally this can indicate not putting an effort into it, which reflects poorly on your programming skills. So I recommend cleaning up on it a little bit. Again, not attacking you; just recommending something.

Those of you who view this post as harsh, go away.
Those of you who have genuine corrections and criticisms (either beneficial to me or others), please share them.


Don't forget to mention that

Ivan Vučica's picture

Don't forget to mention that autorelease is an even better way to approach most of the work with objects, as long as you are careful:

MyObject *obj = [[[MyObject alloc] initWithArgument:arg] autorelease];

or even, if you write object well (or if the object is written well):

MyObject *obj = [MyObject myObjectWithArgument:arg];

in which case the conventions say the object will be allocated and autoreleased. Then, one can retain the returned object, or just leave it alone. In mainloop it'll be released, and if it wasn't retained, it'll get deallocated as well.

I love autorelease.

Speaking language and Computer language is 2 different thing.

Anonymous's picture

> Your English does not appear to be well structured. Normally this can indicate not putting an effort into it, which reflects poorly on your programming skills.

What a theory behind this ? English on forum and on program code is two totally different thing. we are not written an essay here, neither an English-Literature.

In code, of-course it have to well structured, otherwise hard to maintenance and read.

In an analogy, people with keypad only handphone wrote a SMS "whre r u, bro ?" does not mean his is not well structured, it only mean spelling error and/or limited time, or write in rush hour.

In second analogy, All non-Enlgish speaking programmer have bad-structured code, because their english is not well structured as appear on forum. So the German cannot write a good program (sorry Siemens, Sorry SAP), neither France and Russia. Neither the Jap, The Korea and the China etc.

> So I recommend cleaning up on it a little bit. Again, not attacking you; just recommending something.

Time problem .... just have time to clean up in the code, not in forum comment. Apology if it cause hard to read.

Your are being racist and

Anonymous's picture

Your are being racist and offensive to people who don't speak English natively, also your comment is full of grammar errors.

Programming languages are not English, they just generally use English keywords. I have spoken to many people concerning this issue in the past, and all of the people claim that poor English skills do not affect their programming.

Please think about your responses more in the future.

Some of point is true, yes, I

Anonymous's picture

Some of point is true, yes, I admit (most programmer actually) am attachking the IPhone SDK, Obj-c might be innocent on some point.
ie, it is implementation problem, not solely language itself.

Below are some comment, not personal attack, just some factfull info / feedback. Also, it seem you work lot on theory, not much on practical - theory and practical not always tally.

below as some comment:

>> when can free the object ?
> Try something along the lines of [myobject release]; There are also
> auto-release pools that allow for the object to be released when the
> pool is released. This simplifies programming to an extent.

Of course we know we can release like [obj release], the problem is we must keep a record of whether the 'myobject' have been released or not, otherwise if it already released, call release again will cause the App crash.

Not to forget that the "suppose to be" retainCount - is NOT working.
(or maybe, I'm wrong, but at least - it is NOT working on IPhone SDK).

Autorelease pool is also "suppose to work", but it is not, for eg, it release time is not determistic, many time, in a loop, we have to explicitly free the obj, thus memory after the obj have been used, not until the whole method, or even worst, the App exit, otherwise if the memory not released by autorelease in time, the memory will used up and the App crash also.

>> Obj-C memory handling definately add up very much time on the development time and resource.
Provide a solid example of this. Objects are allocated quite easily.

> MyObject *pObj = [[MyObject alloc] init];

This is only in the simple case, most obj have something to init during it allocation.

Of course number of years in develop program not equal expertise, I see many can only wrote in some language like VB6, VB.net stuff and only wrote simple App. However, number of years in writting proven commerce / industrial grade program/App is.

Typing Error Correction (2)

Anonymous's picture

> if the object forget to free, the app will crash. There is no constructor and destructor as in C++ and JAVA, and it is not possible to support something like.

It read :
If the object forget to free, it cause memory leak, if the object is "over-free", it cause the App crash.


some statement ....

obj1 = [[theObject alloc] init];

< some code >

[obj1 release];

< some statement ... >

// Tentatively, this way should work, but it is NOT.

if [[obj1 retainCount] > 0]
[obj1 release];


The retainCount not work correctly can cannot be rely on (non arguable, officially confirmed). after the first obj1 release, retainCount NOT neccessary will be minus 1 after the release call. Anyone rely on the retainCount will cause either cause memory leak (not released due to the retainCount say == 0), or crash (called release cause the retainCount say it is > 0).


Typing Error Correction

Anonymous's picture

> About Java, one of problem is the code cannot divide into separate file. (whereas all other C++ variant can, include C#).

Typing correction, it read:

the "class" cannot divide into separate file (not for different class), ie the source code for a class must keep in the same files.



Anonymous's picture

This article is beyond fail. Quake was NOT developed with Objective-C.
Quake runs on the Quake Engine - developed in C and ASM. It also uses a scripting language called QuakeC for game logic.

Nice try trying to make Objective-C hip.

not exactly true, the

Anonymous's picture

not exactly true, the original QuakeEd used objective-c

so if you interpret the quote in the artical
"some famous games including Quake and NuclearStrike were developed using Objective-C."

as, objective-c was used during the development of quake, the statement is completely true.

A game and an application for

Anonymous's picture

A game and an application for a game are very different. For games, you usually care a lot about speed. Implying that the game itself was made using Objective-C is saying "Objective-C is fast enough for demanding games" (as Quake was pretty demanding back in the day). Most game developers choose C++ because it's such a fast language that still offers object-oriented programming.

Now, speed may be less of a concern for a lot of games nowadays, but one has to wonder how much of a benefit Objective-C's benefits are to games. Accepting any method? Well, that's fairly neat. Most games use an event-based messaging system. In C++, this is coded as an inherited class attribute. It doesn't take a ton of time to hookup and the implementation is inherently faster than the Objective-C equivalent.


Anonymous's picture

A language is not just it syntax, but many other things as well. When your choosing a language to learn and develop in it's vital to consider several factors first:

1) How big is the community behind the language? The bigger the community the higher the probability the language will survive. When a community is big you can count on ports to other platforms, new libraries, feedback on language issues, articles that instruct how to use the language. Essentially the bigger the community the better the support.

2) Is the language open-source or closed source? If closed source, be prepared for the possibility of paying ridiculous fees in the future to use essential tools, libraries, or IDEs

3) Does the language and it's environment rely on any proprietary, or closed-source code (i.e. dot net). If so you risk having to pay future fees to produce commercial software, or being sued.

4) How many developers are there to the language? If relativly few then the language risk being underdeveloped. If there is only one developer and the language is closed-source--what happens if that developer is hit by a bus and dies?

5) Does the language support constructs that make it easy to develop applications rapidly without a serious performance hit? OOP isn't just about pretty abstractions, it's also about efficient designs that catch bugs, in the context of large teams.

6) Wrestling with a compiler and linker in order to get a third-party library to work is hell. This is one of the key reasons so many libraries have reinvented the wheel.

7) What is the learning curve for the language? Does an entrant to the language have to know complex mathematical concepts, or anything else that might prove to be a barrier?

8) Is the language so flexible that it sacrifices performance, readability, and maintainability (I'm looking at you Lisp).

9) Is the standard designed by a single person (or a *very* small group) or is it designed by committee. Cplusplus suffers from the design-by-committee flaw. Look at the D programming language. I can't say it's elegant, but it certainly is less of a headache to work with.

10) Is the documentation and reference material clean, organized, up to date, and regularly maintained? Does it provide articles on complex issues, tutorials for beginners, examples on implementation, and is it easily accessible in multiple formats (web, pdf, etc).

11) I realize some relatively small, and powerful languages (like Eiffel or Ruby) come with books to assist developers, but you have to pay. This is not necessarily a bad thing, but it's not a good thing either. Look at C, and C++ and you will find plenty of web-based books that are free.

12) Is the language natural and intuitive? The reason OOP and Procedural languages are so popular is because people naturally think in terms of objects, and procedures. Yes, I'm aware some of you functional-programs only think and lists, maps, monads, and closures--but your the exception, not the rule.


Anonymous's picture

"Quake and NuclearStrike were developed using Objective-C."

Famous game ? How about the top-10 game like 'Need for speed', 'Command and Conquer', "War Craf" ? There are in C++, not objective-C.

"A decade is an eternity in the software industry. If the framework (and its programming language--Objective C) came through untouched these past ten years, there must be something special about it."

Can be two reason:
1. It is too good that no need to change.
2. It is too bad that no nobody care, or use.

Small talk ? How many commercial, big-project is using small-talk nowaday ?

The top-10 language ranking itself told itself.

Objective-C only now get alive because of IPhone. but how long will it keep ? esp when rival strike back, like Nokia, Samsung, Blackberry, Window-Mobile 7. (no one is using Objective-C).

The lame strikes back? Hahaha.

MikeFM's picture

Good luck with waiting for Nokia, Samsung, Blackberry, or Windows Mobile to strike back. They never understood how to make a good device or operating system and there is no reason to think they ever will. They have always had crap developer programs and expensive tool chains which is no doubt a strong factor in why apps on those platforms are so few and have so much suck value.

Besides you can compile C and C++ into Objective-C programs. Good programmers can work with multiple languages and environments. It's a rare day that I don't work in at least half a dozen different programming languages and four or five operating systems.

It is about productivity and reliability.

Anonymous's picture

Come on, let think rationally, how much commercial and industry software is developed / using Objective-C ?

Even Apple and IPhone Kernel itself is not using Obj-C, only it App.
(IPhone and some Macintosh OS is running Linux, nothing to do with Obj-C).

What we see is Objective-C is used only in expendable platform, like IPhone, where it functionality is not critical and crashing the App will not cause fatal consequence, like Game, Leisure, News App, etc.

For eg, if your know SCADA system, there is zero (0) SCADA software developed using Obj-C. (otherwise, human-live have been eliminate from earth due the the SCADA program crash).

Just see the application crash ratio on App Store. Almost 100% of the App, especially version 1.0, having crash problem. This does not happen on other platform. and it clearly shown there inherited a problem on the language itself. For eg, the "retainCount" method - exist but not work, even offically say so.

About the number of App in AppStore is greater than other, this is questionable. for eg, WindowsCE does not have store, due to many reason, for eg,

Also, it is not true other platform need expensive tools to develop, I have been using Embedded VC++ for WindowsCe since 1999. And J2ME development tools since 2002, PalmOS toolkit since 2000, Symbian C++ SDK since 2003, non of them need to paid to distribute the app to device.
(But for XCode, we need to buy the cert for distribute to device, and NOT once, but every year as long as you want your app on App store).
Also, non of them need huge 2.4+ GB of download on each new version release, even just minor update, for eg, just from 3.0 to 3.1, the whole SDK need to redownload.

You can say the App crash is due to poor programmer skill, but the crash happen also for big-name App like CNN and BBC App, where there have resource to employ the best programmer around the world, so there no need to employ cheap one.

It is true that Good programmer can work with any language, but the different is productivity and time to develop. Of course you can use assembly lang to develop an accounting software, but does it make sense ?
(unless you are R&D student in U that use tax-payer funded government fund to do this way, for eg, use 10 years to write a simple accouting app for own use)

WindowsCE, not only exist on Windows-Mobile device, but in many embedded system as well, where it reliability have been proven and used in many commercial system, like industry grade handheld devices by Intermec, Held-Held Computing Dolphin series, Symbol, etc.

IPhone get popoluate also largely due to it come on the right time - with 3G network available and polular, whereas WindowsCE have been exist on time even GPRS does not exist.

Apple choose Obj-C for it SDK is also largely due to Apple own Objective-C (and pround of it), and it Mac App is also Obj-C based also.


Anonymous's picture

Some addendum
> For eg, if your know SCADA system, there is zero (0) SCADA software developed using Obj-C. (otherwise, human-live have been eliminated from earth due the the SCADA program crash).

I mean here is SCADA system used in Nuclear Power Plant.

> About the number of App in AppStore is greater than other, this is questionable. for eg, WindowsCE does not have store, due to many reason, for eg,

One of the reason is that there is too many WindowsCE program developed, almost every programmer in the earth involve partly, or fully in Windows platform, Just imaging, if there 1 IPhone App programmer, there is at least 100X WindowsApp programmer, if there is million of IPhone App, there is at least Trillion of WindowsCE App exist, this is not kidding, Microsoft will need a very very huge resource on evaluate, checking and approve the App and hosting the App, and the transaction if the app is a paid App. Also Windowsce, Java Mobile App etc, no need to depend on App Store to distribute, (can distribut directly) so there is no such a must need for App store, and the number of App on these platform (WindowsCE, Java, Symbian etc) cannot be counted.

> Apple choose Obj-C for it SDK is also largely due to Apple own Objective-C (and pround of it), and it Mac App is also Obj-C based also.

I mean here there (stupidly) pround of it due to it is developed from them (directly or indirectly), not because it is the developer favourite choice / prefered lang.



Anonymous's picture

What are you, 12?

Be constructive and factful

Anonymous's picture

Be constructive and factful debade, not personal attack. dont act like child.


Anonymous's picture

For those app developers that don't know Objective-C and Cocoa Touch and don't want to outsource development, check out localbeacon (an iphone app builder) at www.bigforge.com. Great for those who want to build just one app or developers interested in white label. Full integration of Twitter and Facebook.

Source for the List example portion of this tutorial...

Anonymous's picture

Source for the list portion of this project for NEXTSTEP 3.3 is now available at this link (or until the site closes)...


The Project Builder project I created is a command line tool, not an application. Also the classes have been named so there are no name collisions with the NS Foundation class library installed in NS 3.3 Developer.

The PB project is set to build quad fat, select Options in PB and deselect the platforms you don't want.

Here is the output of the run.

--- start paste of output
NS33> ./ListProject

5 3
sum: 10
no clue!
--- end paste of output


window maker is NOT a GNUstep application.

Anonymous's picture

Since [ ... ] the fact that GNUstep is delivering the rock-solid window-manager Window Maker, Objective-C is (rightly) getting more attention

window maker has nothing to do with GNUstep except the looks and it being the only window manager that works well with GNUstep currently. hopefully it will soon be replaced by a real GNUstep window manager

Re: Objective-C: the More Flexible C++

Anonymous's picture

What is this "she" crap all about? Can we please stick to programming and not social agendas? We just want to program.

Appreciated the info about Objective-C by the way.

What is this "What is this 'she' crap" crap all about?

Anonymous's picture

Get a life and stop whining / nitpicking about small things like this.

Re: What is this

Anonymous's picture

He wouldn't have nitpicked about it if the author hadn't.

That's backwards. Having to

Anonymous's picture

That's backwards. Having to bend over backwards to say "he/she" every time is more nit-picky than just picking a pronoun and using it.

What possible "social agenda" does one promote by using "she"? (I guess if you're living in the 1950's, the idea that women are doing something outside of the kitchen is pretty radical, but we haven't been living in the 1950's for a couple years now.)

Oh come on, we all know the

Anonymous's picture

Oh come on, we all know the vast majority of programmers are males.
The author is clearly trying to get a message across.
If I was writing an article about construction, I would use "he"; if I were writing about shopping, I'd use "she".

This is very strange. I am

Moomy's picture

This is very strange. I am a woman and I am learning Objective-C, as are several of my female friends. Seems very normal for women to do this.

Like minds tend to attract.

Anonymous's picture

Like minds tend to attract. If you're learning a language, I'd expect a portion of your friends to be equally interested.

The majority of programmers are male, and this hasn't changed. Yes, I know a number of females who program, but I know a lot more males who do. Females also tend to be more hobbyist programmers than males.

Really? That's news to me.

Katie's picture

Really? That's news to me. At every company I have ever worked, female developers have slightly outnumbered male developers. The ratio is roughly 1:1. I think you may be using an out-of-date version of reality. Try fetching the latest version from your distro's repos. I'm pretty sure sexism was deprecated in the '60s.

HAHAHA I love that reply :D

Anonymous's picture

I love that reply :D


Anonymous's picture

Nicely said.

either way

Anonymous's picture

I find it sexist either way, if an author were to use he or she in such an article. Why not use they? it fits in the context just as well and keeps people from arguing about such nonsense

What about IT

Anonymous's picture

Or we could just reply to everyone all the time as "IT" until someone had the opposite reaction and then we'd just go back to he/she as we felt and no one would even notice let alone care whether he or she was said.

In the end it doesn't really matter and I don't think any reasonable person is offended by the use of he or she interchangeably.

Re: Objective-C: the More Flexible C++

Anonymous's picture

I don't think the author's choice of words took away from the article, but this comment does! If it wasn't for mine and your post all comments would have been about programming. I guess you got to follow your own "social agenda" huh?

What ?

Anonymous's picture

The fact is the author initiated the query with the comment (for whatever reason ... which I believe is the original responders complaint/comment). It certainly didn't add to the article ... so why make the quip ?

Re: Objective-C: the More Flexible C++

Anonymous's picture

as close to Smalltalk as a compiled language can be.

Uh, Smalltalk is a compiled language. So the closest thing to Smalltalk that is a compiled language is Smalltalk itself!

Re: Objective-C: the More Flexible C++

Anonymous's picture

Uh... check your facts again. Smalltalk is interpreted.

Languages are neither. Imple

Anonymous's picture

Languages are neither. Implementations are.

FWIW, most implementations are compiled (to bytecodes).

By this argument, Python,

Katie's picture

By this argument, Python, JavaScript, and Perl are all compiled languages. The only useful distinction between a "compiled language" and an "interpreted language" is "a language whose standard implementation compiles source code to object code designed to be run directly by a hardware processor (with a caveat for VMs)" and "a language whose standard implementation either interprets source code directly or interprets a bytecode format derived therefrom."

A more useful distinction lies between "static" and "dynamic" languages, of which many languages are arguably hybrids.


Re: Objective-C: the More Flexible C++

Anonymous's picture

> some famous games including Quake and NuclearStrike

> were developed using Objective-C.

Quake was not written in Objective-C. Anyone can verify this in two minutes by downloading the source code from Quake.com. Carmack did write a level editor called QuakeEd in Objective-C, but the game itself was not. Please update the article to avoid misleading people into thinking that Carmack would write a game in Objective-C.

> Objective-C is (rightly) getting more attention because

> it is more flexible than C++ at the cost of being slower.

Most of the Objective-C constructs can be implemented in C++ without much difficulty, but the inverse is not true. C++ is more flexible, end of discussion.

> Compile-time and link-time constraints are limiting because

> they force issues to be decided from information found in

> the programmer's source code, rather than from information

> obtained by the running program.

Wrong. See any major API written in C. Let us take Win32 as an example. It is written in C, a statically-typed language, yet I can superclass windows as I please while the API DLL's are running. That is not so odd once you consider that dynamically-typed langauges are implemented using statically-typed languages. Your own explanation of the C underpinnings of Objective-C features confirms my point.

How about no?

Katie's picture

All languages are equal in expressive power. This is a core tenet of linguistics and computer science alike.

The bottom line is any Turing-complete language can accomplish any computable task. It is utter absurdity to claim that any one language is "more flexible" than any other. They can each do anything.

Just as surely as you could write a C++ compiler in Objective-C (though why you would do this is anyone's guess), you could similarly insanely write it in brainf*ck or Python.

So can we please top the language war flames? This is as insane as claiming that Chinese poetry is more flexible than Turkish poetry.

Re: Objective-C: the More Flexible C++

Anonymous's picture

Most of the Objective-C constructs can be implemented in C++ without much difficulty, but the inverse is not true. C++ is more flexible, end of discussion.But C++ is ugly as ***** and confusing as hell. Objective-C is neither of these things. And you will never find a better set of frameworks than OpenStep.

Re: Objective-C: the More Flexible C++

Anonymous's picture

> Most of the Objective-C constructs can be implemented in C++ without

> much difficulty, but the inverse is not true. C++ is more flexible, end

> of discussion.

By this "logic", assembly is the most flexible language.

Re: Objective-C: the More Flexible C++

Anonymous's picture

> By this "logic", assembly is the most flexible language.


Most of Objective-C's "dynamic typing" features hinge around being able to pass messages around via a very simple run-time system. This system can be easily and cleanly wrapped into C++ code that greatly resembles the Objective-C constructs in simplicity and usefulness.

You cannot draw the same comparison between C and C++, between Objective-C and C++, or even between assembly and most other languages. Hence, C++ is more flexible than Objective-C.

Re: All right, I'm curious...

Anonymous's picture

Would you please give us some examples... I guess they would come up pretty ugly if you truly want to "emulate" Obj-C messages in C++..

How about protocols and "protocols-inheritance"?

If anyone is able to do it cleanly in C++ I would be _extremely_ surprised... so, surprise us!

C++ is more "flexible" when you make C++-oriented programs: Obj-C is different and it does not need much of C++ features (some are nice, I admit, you can use Obj-C++ for them)... If you compare the runtimes Obj-C is a lot more flexible than C++!

Re: All right, I'm curious...

Anonymous's picture

*yawn* It sure is late! I have already implemented the message inheritance thingamajig already without much trouble, but I will post it sometime tomorrow once I have had a chance to clean up the development cruft.

Here is an example of dynamic dispatch...

Anonymous's picture

// This is the class that makes it all possible:

class id


int t;


id (int type) : t (type) {}

virtual id* dispatch (int action)


return on_unknown (action);


virtual id* on_unknown (int action)


throw exceptional::runtime_error ("object does not support this action");


int type () const { return t; }


// Here we have defined some objects and actions for convenience:

namespace objects {

enum {






namespace actions {

enum {





// And here are two example classes:

class example1

: public id


typedef id base;


example1 () : base (objects::example1) {}

id* dispatch (int action)


switch (action)


case actions::foo: return on_foo ();

case actions::bar: return on_bar ();

default: return base::dispatch (action);



id* on_foo () { cout dispatch (actions::foo);

p->dispatch (actions::bar);

p->dispatch (392075);


// And our test main function - play around with it a bit!

int main ()




id* p1 = new example1;

id* p2 = new example2;

dispatch_foo_and_bar (p1);

dispatch_foo_and_bar (p2);


catch (runtime_error& e)


cout << "runtime error: " << e.what () << endl;



The basic idea is that we have swapped a whole mess of virtual functions for one virtual function, an integer and a switch statement. When a virtual function is called, the most derived class's dispatch function is called. The class attempts to handle the message, but if it cannot, it invokes its base class's dispatch function with the same action parameter. If the base class cannot handle the action, then it invokes *its* base class's dispatch function.

This process continues until either some base class handles the action or it reaches the root class. Naturally the root class, id, is not designed to handle any actions by itself, so it just throws a runtime error.

Re: Here is an example of dynamic dispatch...

Anonymous's picture

Argh! the script ate my example classes and function. :-P

If you cannot guess the code in on_foo etc., please send an email to null_pointer_us AT yahoo DOT com and I will send you a text file attachment containing the code. I would post it on a public server, but unfortunately I do not have any.