C++ versus Objective-C as API substrate

Windows 8 marks the start of the end of the ancient workhorse API – Win32. Win32, along with COM, underlies all other APIs – including .NET – that Windows developers have used. MFC, ATL, COM itself (if I’m not mistaken), etc… these all depend on Win32 underneath.

Starting with Windows 8, all new development going forward is expected to take place with WinRT being the lowest level developer-accessible API. The way I understand it, newer iterations of the .NET Framework will be relying on WinRT underneath. As per [1], WinRT will be a COM-based API albeit supposedly more evolved.

In Stroustrup’s C++ FAQ [2], when asked what he thinks of C++/CLI – which is a way to get C++ to talk to the CLR, he characterizes it thus:

“C++/CLI … essentially augments C++ with a separate language feature for each feature of CLI (interfaces, properties, generics, pointers, inheritance, enumerations, etc…”

The above is essentially what it takes to get C++ to grok the CLR object model!

Thinking about the above, I suddenly realize that before Microsoft invented the One True Runtime To Bind Them All, C++ turned out to be SO INADEQUATE A SYSTEMS LANGUAGE that they essentially had to layer a whole infrastructure on top of it – COM – with its own huuuge panoply of conventions [3], in order to make it possible to use as an API substrate for the newer stuff they wanted to make available to Windows developers. Recall that COM was introduced because the more vanilla C++-based APIs, e.g. MFC, turned out to be inadequate (I have a very good reference discussing this which I can’t seem to recall right now…).

As a COM developer, you not only had to master the already humongous list of C++ dos and dont’s, you then had to do the same for COM’s conventions… but you basically have no choice if you intended to take advantage of Windows APIs from C++.

If one looks at the evolution of C++-based APIs on Linux, pretty much the same issues arise. VANILLA (if you could call the hideous chopsuey of syntax and conventions that is C++ ‘vanilla’) C++ alone NEVER CUTS IT, everyone has to layer some BIG piece of proprietary plumbing on top of it to get work done. You’ve got Qt with its meta object compiler moc (and god-knows-what-else), KDE with its DCOP, Mozilla’s XPCOM (and just for writing a browser!) etc…

Basically, each of these project/environment comes with its own reinvented object model/environment conventions that you have to pick up in addition to C++! So much for the notion of “C++ code portability”…

I believe much of the gunk above has to do with the lack of DYNAMIC BINDING in C++. It seems that Jobs, Tevanian, et al… made the right call way, way back when NeXTStep was born.

There seem to be two roads that one could have taken:

1) Objective-C with its “one syntax addition” and few dozen keyword additions to C, enabling dynamic dispatch and the other goodies of the Smalltalk object model (including concise, no-nonsense reflection facilities) to interoperate intimately with C.

2) Deal with all the gunk in C++ and then, additionally, reinvent a memory management model (e.g. reference counting in COM), method dispatch, reflection, and on and on and on and on… to put on top of C++.

In OS X, just about the only place where C++ lives is as a glorified template language (chuckle) for – ironically enough – device driver writing (to avoid the copy-paste of common driver code) in IOKit [4]. And this in the form of Stroustrup’s much hated Embedded C++ [5], while the rest of the APIs are implemented as either pure C (e.g. the CoreXXXXXX APIs) or Objective-C.

References:

[1] http://mdavey.wordpress.com/2011/09/19/win8-more-thoughts-on-winrt-projections-and-possible-roadmap/
[2] http://www2.research.att.com/~bs/bs_faq.html
[3] http://books.google.com/books/about/Essential_COM.html?id=kfRWvKSePmAC
[4] @18:15 – http://www.youtube.com/watch?v=-7GMHB3Plc8
[5] http://www2.research.att.com/~bs/bs_faq.html#EC++