You can even use C++, too, which is awesome. Putting Objective-C objects in C++ structs "just works" thanks to ARC.
One thing most people don't know is that Objective-C was originally implemented as a precompiler for C.
Source: https://en.wikipedia.org/wiki/GNU_General_Public_License#Leg...
> In order to circumvent the terms of the GPL, NeXT had originally intended to ship the Objective-C frontend separately, allowing the user to link it with GCC to produce the compiler executable. After being initially accepted by Richard M. Stallman, this plan was rejected after Stallman consulted with GNU's lawyers and NeXT agreed to make Objective-C part of GCC.
Source: https://en.wikipedia.org/wiki/Objective-C#Popularization_thr...
No.
Objective-C was developed in the early '80s (as a C pre-processor, as the Grandparent post said) by Brad Cox, and commercialized by himself and Tom Love via a company they created together called Stepstone. Cox wrote a book about their product, Object Oriented Programming: An Evolutionary Approach, in 1986. I own a copy. It's pretty good!
Some time later, NeXT decided to build their user-space APIs around Objective-C, and bought the rights to Objective-C from Stepstone outright. It was at that point that they started modifying GCC to directly compile Objective-C rather than pre-process it into C.
In particular, in the beginning Objective-C was a lot looser typed at compile time than it is now: no NSString* or NSWindow*, it was all just id. It was an attempt to make C look like Smalltalk.
The language eventually evolved more toward the static-typed end of the spectrum, culminating in support for lightweight generics and ostensibly birthing Swift along the way.
No. Objective-C started out as a set of C Macros, then an actual pre-processor was created, mostly to deal with uniquing selectors. Once the pre-processor was there it was used to create actual syntax.
Documented in "Object Oriented Programming: An Evolutionary Approach".[1] Still one of the best books on OO out there, because it treats OO as an architectural style with tradeoffs relative to other styles, rather than as a religion to be accepted (or nowadays as the devil to be cast into hell).
It also clearly describes the deliberate hybrid style that seems to be mostly forgotten now: object largely implemented in C, but connected via dynamic messaging. "Software-ICs".
I am somewhat surprised by seeing the 1986 release date, I guess I must have gotten it pretty soon after it was published. Used it as a template to implement an Objective-C pre-processor + runtime + basic classes on my Amiga (had just gotten a C compiler for it).
One of the reasons I got a NeXT was because NeXTStep was largely implemented in Objective-C, which to me meant they "got" it. And it also meant I could enjoy programming in Objective-C without having to maintain my own :-)
[1] http://www.amazon.com/Object-Oriented-Programming-Evolutiona...
I'm curious. What did that early form of Obj-C look like?
another thing most people forget is that the entire programming community rejected obj-c as deficient in its very early days... it only persists thanks to the ego of former nextstep employees afaik. and now apple employees got lumped with it... which i'd suspect helped create the internal pressure for swift... so some good came at the end of it all. :)
It's not worth listening to anyone who dislikes Obj-C just because of the [] syntax, which doesn't matter after the first 48 hours.
http://twistedoakstudios.com/blog/Post8237_a-years-worth-of-...
Not true anymore; ObjC has generics with type erasure. (But not all the cases can be exported to Swift.)
> Instead, Objective-C has nil, which is like null except it won’t stop the program when you accidentally use it.
That's… not quite right… but I guess he has the visible effects down. Anyway, ObjC has nullability annotations now for this.
> For example, in Objective-C many objects have both a “core foundation” form and a “new style” “NeXTSTEP” form
This is not legacy baggage, it's an intentional C bridge.
> This is justified by conventions strongly favoring you not catching exceptions, and apparently the speed benefits are non-negligible, but it still blows my mind that Apple has their language default to incorrect behavior.
He shouldn't use ARC+exceptions, because Cocoa itself is not exception-safe. Just quit the app if you get one.
That's pretty much my thoughts these days. If you have only the most superficial understanding of these languages, then that's what you'll get caught up on, but that's like saying Java and JavaScript are similar because they both use curly braces and dot notation for their methods. Yea, that is true, but it's a superficial similarity.
https://infinum.co/the-capsized-eight/articles/android-devel...
The same goes for C++ or Swift. Getting the function pointer for a method can be involved, but all functions adhere to the C ABI.
Just write an asm stub to call, that sets up ecx and other things right.
This is clearly false since at least one C++ compiler generates functions that does not adhere to any of the common calling conventions for C on that platform (or "C ABIs" if you will).
Besides that, I said you could not call them from C. An asm stub is not C. Neither is inline assembly even though it's a common extension to C.
they break it on tiny incremental updates sometimes... at least historically (in fairly recent history at least).
Some x86 C compilers supports calling conventions that lets you put things in registers, e.g. Microsofts "fastcall". But I wouldn't consider that part of the standard "C ABI" for Windows given that it's practically never used for externally visible functions. As I said "without specfic compiler support".
Using inline assembler is just cheating, it's not C.
> but cl is easily the worst compiler for a C++ ABI. they break it on tiny incremental updates sometimes... at least historically (in fairly recent history at least).
That is more about name mangling schemes and layout of standard library classes though. As far as I know the calling conventions has been quite fixed for a long time.