作為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的實現。

原文參考：C++ versus Objective-C as API substrate