作为API基板的C++与Objective-C
C++ versus Objective-C as API substrate （作为API基板的C++与Objective-C）
翻译：赵毅力
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.
Windows 8的启动标志着Windows操作系统中古老的主力API – Win32的终结。 在Windows操作系统中，Win32和COM是所有其他API – 包括.NET的基础，Windows开发者使用的MFC，ATL 和COM本身（如果我没有记错），等等……这些都在底层都依赖于Win32。
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.
从Windows 8开始，所有新的开发将依托WinRT作为最底层API。我的理解是，.NET Framework的新迭代也将依赖于WinRT。按[1]所说，WinRT将是一个基于COM的API。
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…”
在Stroustrup的的C++常见问题[2]中，当被问及他对的C++/CLI （这是一种使得C++和CLR可以互操作的方法）的看法时，他回答：
“C++/CLI的…本质上是增加了CLI特性的增强版的C++。需要增加的CLI特性包括：接口，属性，泛型，指针，继承，枚举等功能……”
The above is essentially what it takes to get C++ to grok the CLR object model!
以上基本上涵盖了C++需要和CLR对象模型进行通信的要点。
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…).
对上述问题的思考，我突然意识到，在微软发明一个能够绑定一切的运行时以前，作为一个系统编程语言，C++是如此的不足，以至于他们需要在C++语言上面构建一整个基础设施 -即COM – 以及COM的一整套公约[3]，其目的是为Windows开发人员提供一个API基板。回想起当时COM的引入是因为越来越多的以C++为基础的API呈现出很多不足，例如： MFC（我有一个很好的参考，讨论这个，我不能现在依稀记得…）。
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++.
作为一名COM开发人员，你不仅需要掌握已堆积如山的关于C++能做的和不能做知识点，你还不得不掌握同样多的关于COM的一大堆约定…如果你打算通过C++利用Windows API的优势，你基本上已经别无选择。
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…
如果观察Linux操作系统上的基于C++的API演变史，会发现几乎出现同样的问题。每个人都不得不在C++上面构架一个专属的大框架来完成工作。例如Qt的元对象编译器moc，KDE的DCOP，Mozilla的XPCOM的等…
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”…
基本上，除了C++本身，这些项目/环境每个都有自己重新发明的对象模型/环境约定！
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.
我相信上面提到的重新构建框架的大部分原因是因为C++缺乏动态绑定。看起来似乎乔布斯，Tevanian在设计NEXTSTEP系统的时候作出了正确的选择。
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.
1）使用Objective-C语言，开启动态调度和Smalltalk的对象模型（包括简洁的反射能力），并与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++.
2）处理所有和C++有关的问题，此外，在C++的基础上重新发明内存管理模型（如COM中的引用计数机制），构建方法调度，反射，以及其他更多需要的东西。
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.
在OS X操作系统中，C++唯一存在的地方就是用于IOKit设备驱动程序编写（避免了常见的驱动程序代码的复制粘贴）[4]。而这正式Stroustrup的非常讨厌的嵌入式C++用法[5]，而其余的API，要么是纯C实现（如CoreXXXXXX的API），要么是Objective-C的实现。