Take the 2-minute tour ×

From what i read there: Why is Objective-C not very popular outside of the Apple community?

Objective-C is a superset of C (much more strictly than C++, in fact) so the issue of backward compatibility does not arise. Anything you can do in C you can do in Objective-C.

Being a superset is binary, like being pregnant. Obj-C is a superset of C, and C++ is not.

What do they mean by superset? In what way does objective-C would be more close//backward compatible to C? In what way does objective-C follow the C philosophy more closely than C++?

Can any C program be compiled without modification by a objective-C compiler (100% compatibility)?

This is more a question about programming language design and compatibility than a wars about which one is better.

share|improve this question

5 Answers 5

up vote 101 down vote accepted

I prepared a simple diagram; it is not very pretty, but hopefully gets the point across:

  • Red: the set of all programs valid in C, C++, and Objective C (relatively small)
  • Green: the set of all programs valid in C and Objective-C, but invalid in C++ (even smaller)
  • Gray: the set of all programs valid in Objective C and C++, but invalid in C (empty, as far as I know)
  • Blue: the set of all programs valid only in Objective C (relatively large)
  • Yellow: the set of all programs valid only in C++ (largest)

The set of valid C programs (in red and green) is an strict subset of the set of valid Objective C programs (blue)

enter image description here

share|improve this answer
What about objective c++? –  user1115057 Oct 14 '13 at 22:19
Strange resemblance... : justindomke.files.wordpress.com/2008/11/scalaimage11.png –  user1115057 Oct 14 '13 at 23:59
By what measure do you claim yellow is "larger" than blue here? Intuition tells me that both sets would be countably infinite. –  wim Oct 15 '13 at 0:26
@wim: And both are represented as uncountables subsets of R^2 ;) This is the same trick as you will see N inside the Q despite them being the same size (and N being strict subset of Q). –  Maciej Piechotka Oct 15 '13 at 0:41
I was thinking about it some more, and realized that the ObjC++ set would not actually surround all of this. It is a superset of C++, but not a strict superset of ObjC. The same programs that are legal C, but illegal C++ (the green area) are illegal ObjC++. –  Rob Napier Oct 15 '13 at 13:23
  1. What do they mean by superset?

    They mean strict superset. Any valid C program will compile with an Objective-C compiler. Some valid C programs will not compile with a C++ compiler.

  2. In what way does objective-C would be more close//backward compatible to C?

    Here's a simple example:

    int *foo = malloc(12);

    Compiles in C and Objective-C, but not in C++. There are, of course, other examples as well.

  3. In what way does objective-C follow the C philosophy more closely than C++?

    All - Objective-C is a strict superset of C.

  4. Can any C program be compiled without modification by a objective-C compiler (100% compatibility)?


share|improve this answer
Yes, that would be fine. Arguably you don't need Objective-C for the GUI, either, if you're willing to figure out the low-level runtime functions to use. –  Carl Norum Oct 14 '13 at 18:03
Mostly philosophical. –  Carl Norum Oct 14 '13 at 18:04
+1 Great explanation. I would suggest that the question of "the C philosophy" is a bit vague, but most observers would probably agree that the "goals" of C and the "goals" of ObjC do differ. C's intent is to be very close to the hardware, while providing some useful portability abstractions, while ObjC's goal is to bring a SmallTalk approach to C. As Cocoa has become integral to ObjC in recent years, this divergence is even stronger. The "philosophy" (design approach) of a C-array and an NSArray are certainly very different. –  Rob Napier Oct 14 '13 at 18:05
That depends entirely on the program. Probably you wouldn't do too many C-style things in an Objective-C program. Why would you use Objective-C then? –  Carl Norum Oct 14 '13 at 18:12
@user1115057: you shouldn't worry too much about how things are considered. There are two problems with writing C++ code that compiles as (or at least looks like) C. One is that you aren't getting any of the benefits of C++, but that's your call. The important one is that you're writing in a broken dialect of C that isn't really C. You should instead compile your C code with a C compiler and link it against your C++ code. That latter concern doesn't apply with Objective-C, since the subset of Objective-C that compiles as C, is C. –  Steve Jessop Oct 14 '13 at 18:13

From the ground up, C++ has been designed as a "better C", fixing design omissions, both real and perceived, as the authors of C++ went through the language. The result of this design decision has been that X being a valid C program did not guarantee that X would compile, let alone run, when processed by the C++ compiler. The changes touched such basic constructs as string literals (they became const char*), assignment of void pointers, conversions between enums and integral types, semantics of compound assignment operators, and so on.

Moreover, once C99 came along, features that made it into the updated C standard were left out from the updated C++ standard. Again, very important language features were left out - most notably, designated initializers and variable-size arrays.

In contrast, Objective C has been positioned as a superset of C, requiring all valid C programs to be compilable with an Objective C compiler.

share|improve this answer
I've answered this question because I know what a "superset" is, but I don't know anything about Objective-C. I've seen a claim in another SO question, that the valid C code snippet int nil = 0; nil++; doesn't compile as Objective-C. What's the problem there, is it the obvious thing that Objective-C makes available headers that, once included, can break your code exactly as C headers can? And hence the author of that snippet shouldn't have included them. –  Steve Jessop Oct 14 '13 at 18:09
"nil" is actually a #define rather than a keyword. You're seeing problems because objc/objc.h is included. This is similar to the problems you'd see if you tried to make a variable called YES. (Xcode highlights these as though they were really keywords because it's much easier to think about it that way; but they're implemented as simple C code.) –  Rob Napier Oct 14 '13 at 18:22
BTW, it's worth poking around objc.h a little if you're interested in how ObjC lives on top of C. Things that you would think would be keywords (id, BOOL, Class, nil, etc.) are just simple types, structs, and defines. You can even implement message passing by hand in pure-C. Never, ever do that. :D But you can. github.com/iosptl/ios6ptl/blob/master/ch28/Runtime/MyMsgSend.c –  Rob Napier Oct 14 '13 at 18:29
@DanNeely: Rob Napier said "never, ever do that" as a commentary about the linked file. The linked file is not the Objective-C runtime, it is just a quick hack that shows some of how messaging really works. –  Dietrich Epp Oct 14 '13 at 22:04
The linked file wasn't demonstrating how complicated ObjC message passing is. It's demonstrates that the runtime is available from C and that you can in principle convert ObjC code into pure C. BUT…this is about as slow as you could build it. It relied on my knowing the return type of the methods (and for some return types, I'd probably need to know the processor type), and I carefully chose methods that take no parameters. The full solution has many subtle tricks (parts have to be in assembler because they cheat with the stack frames). You should never try to rebuild it. –  Rob Napier Oct 15 '13 at 0:20

"Objective-C is a superset of C" means that every valid C program is a valid Objective-C program (with the same meaning).

It is sometimes said, although not by C++ experts, that C++ is a superset of C. This isn't accurate, which is why your quotation is making a big deal of comparing the two.

share|improve this answer

Objective C is a set of backward-compatible extensions to C. This is possible because the Objective C features are delimited in two very simple ways:

  • use of the character @. This character is not currently used in the C language.
  • a simple syntactic extension for invoking methods, [obj method:argument]. In C, square brackets are used in a very specific way for array subscripting, and so this is invalid C syntax. Extensions which build on invalid syntax do not change the meaning of anything that is valid in the host language.

So easy to see that no program which uses Objective C extensions can be a strictly conforming ISO C program, no matter how simple. Moreover, every ISO C program can be declared, by definition, to be a valid Objective C program. Objective C can easily follow developments like C99 and C11.

On the other hand, C++ is not simply extensions to C; it is a different language which changes the meaning of some of the syntax of C. C++ and C are separately maintained, and so their relationship changes over time. For instance, C has acquired new features that are completely absent in C++, and quite likely will not go into C++, such as C99 variable-length arrays. C++ cannot easily pick up new C features.

If you write a portable C program, it should be at the same time an Objective C program. But additional care will be needed so that it is also a C++ program with the same meaning. (This practice is not unheard of, and the dialect it requires is informally known as "Clean C").

A trivial example of a C program that breaks when treated as C++ is any C program which uses a C++ keyword as an identifier, such as class or virtual. Objective C does not introduce any reserved keywords. It has new keywords that are introduced by the @ character, like @interface.

share|improve this answer

Your Answer


