17 年后修复 C++ 已经太晚了。 运行时可扩展性？
1992 年到 1993 年对于 C++ 来说是关键且具有决定性的时期。
在 92/93 年期间，我为 Aldus PageMaker 开发了一个插件架构，它是用 C++ 编码的。 PageMaker 构建在名为 VAMP 的 C++ OOP 框架之上，这有助于其在 Mac OS 和 Windows 之间的可移植性。
所以我们尝试利用C++的特性来构建插件架构。 由于所谓的脆弱基类问题，这对于 C++ 类来说被证明是一个很大的问题。
我继续写了一篇论文，该论文发表在期刊上，并在 OOPSLA '93 的反思研讨会上进行了展示。 您可以阅读我在此处介绍的论文的 pdf 格式：
时间不变C++ 可演化类的虚拟成员函数调度 （翻到底部并点击查看或下载）
我还在波特兰举行的 Usenix 会议上与 Bjarne Stroustrup 取得了联系，并与他进行了几个月的对话，他在会上提出了处理代表我的脆弱基类问题。 （可惜，当时其他问题被认为更重要 - 例如，试图通过批准来引导 RTTI。）
Microsoft 此时为 Windows 平台引入了 COM/DCOM 系统，该系统被视为解决该问题的可行解决方案。 C++ 可以通过用于定义 COM 接口的抽象类用作 COM 的实现语言。
然而，现在开发人员回避 COM/DCOM，尤其是基于 COM 的 ActiveX。 （1994 年，我继续在 Microsoft 工作，并在那里使用了 C++ 和 COM/DCOM，并度过了余下的十年。我得出的结论是，这种技术组合肯定是一个死胡同。我在这里引用了这段经历：构建有效的企业分布式软件系统）
与所有这些早期的 C++ 历史相比， Steve Job 的公司 NeXT 在 90 年代初使用 Objective C 设计了一个插件架构，它是 NeXT Step 框架的组成部分。 如今，这一点在苹果电脑上的 Mac OS X 和 iPhone 等重要平台上依然蓬勃发展。
我提交 Objective C 能够以更好的方式解决插件问题。
Java 的拥护者会引用垃圾收集等因素来解释为什么它比 C++ 更高效。 我不会对此提出异议，但 Objective C 直到最近 2.0 才出现垃圾回收。 在 iPhone 上，垃圾收集仍然不可用。 尽管如此，OS X 插件架构是完全可行的 - 完全归功于 Objective C 风格的 OOP 与 C++ OOP 的优点。
有趣的是，Java 已被用来构建适用于任何平台或软件开发社区的最普遍的插件架构。 Eclipse IDE 插件架构在几年前就合并了 Equinox OSGi 模块管理层，该架构现在几乎已经成为传奇。 J2EE 应用服务器十年来一直支持 EJB 的插件架构。 如今，所有值得注意的 J2EE 应用程序服务器都同样合并了 OSGi 来管理运行时可绑定模块。 Spring 框架及其 Spring Bean 的运行时可绑定单元已经发展到超过了 J2EE——主要依靠其用于管理 Spring Bean 绑定的系统的强度。
Java 社区仍在努力定义官方模块管理标准，但即使如此，Java 平台也比任何其他编程平台更普遍地支持包含插件功能的软件架构。
尽管 Java 作为一种语言相对于 C# 存在弱点，并且 .NET 在其 .NET 汇编标准中已经有了更强大的模块实现，但就广泛使用的包含某种形式插件的日常软件系统而言，Java 仍然领先数年。建筑学。 奇怪的是，Java 社区甚至没有意识到这是他们作为企业开发平台持续成功的基础。
我个人认为C++的脆弱基类问题是它最致命的缺陷。
自这个问题向 C++ 社区和 C++ 的创建者强调以来已经过去了 17 年，现在解决这个问题是否为时已晚？
The 1992 to 1993 timeframe was pivotal and fateful for C++.
In the '92/'93 time frame I worked on a plugin architecture for Aldus PageMaker, which was coded in C++. PageMaker was built on a C++ OOP framework called VAMP, which assisted its portability between Mac OS and Windows.
So we tried to use the features of C++ to build a plugin architecture. This proved to be very problematic for C++ classes due to the so-called brittle base class problem.
I proceeded to write a paper that was published in journals and that I presented at OOPSLA '93 in a reflection workshop. You can read the pdf format of the paper I presented here:
Time Invariant Virtual Member Function Dispatching For C++ Evolvable Classes
(Page to the bottom and click View or Download)
I also made contact with Bjarne Stroustrup at a Usenix conference in Portland and proceeded to dialog with him for several months, where he championed the issue of dealing with the brittle base class problem on my behalf. (Alas, other issues were deemed more important at that time - for instance, trying to shepard RTTI through approval.)
Microsoft at this time introduced the COM/DCOM system for the Windows platform that was looked on as a viable solution to the problem. C++ could be used as an implementation language for COM via abstract classes used to define COM interfaces.
However, these days developers shun COM/DCOM - and especially ActiveX, that was based on COM. (In 1994 I went on to work at Microsoft and used C++ and COM/DCOM there for the remainder of the decade. I came to conclude that the technology combination was a definite dead-end. I refer to that experience here: Building Effective Enterprise Distributed Software Systems)
In contrast to all this early C++ history, Steve Job's company, NeXT, devised a plugin architecture using Objective C during the early 90s, and that was integral to the NeXT Step framework. Today that lives on vibrantly in Mac OS X on Apple's computers and important platforms such as the iPhone.
I submit Objective C enabled solving the plugin problem in a superior manner.
The champions of Java will cite factors such as garbage collection as to why it is more productive than C++. I won't dispute that, but Objective C has not had garbage collection until very recently with 2.0. On the iPhone garbage collection is still not available. None-the-less, the OS X plugin architecture has been entirely viable - due entirely to the merits of Objective C style of OOP vs C++ OOP.
Interestingly, Java has been used to build the most pervasive plugin architectures that exist for any platform or software development community. The Eclipse IDE plugin architecture, which by now is practically legendary, as such architectures go, incorporated a few years ago the Equinox OSGi module management layer. J2EE app servers have supported a plugin architecture for EJBs for a decade. These days all J2EE app servers of note have likewise incorporated OSGi to manage runtime bindable modules. The Spring Framework and its runtime bindable unit of the Spring Bean has grown to exceed J2EE - primarily on the strength of its system for managing the binding in of the Spring Bean.
The Java community is still struggling to define an official module management standard yet even as things stand, the Java platform supports software architectures that incorporate plugin capability more pervasively than any other programming platform.
Despite the weaknesses of Java as a language relative to C#, and that .NET already has a stronger module implementation in its .NET assembly standard, Java is still light years ahead in terms of everyday software systems in wide use that incorporate some form of plugin architecture. Strangely, the Java community doesn't even consciously realize that this is the underpinning of their continued success as an enterprise development platform.
I personally regard the brittle base class problem of C++ to be it's most fatal flaw.
After 17 years have passed since this issue was highlighted to the C++ community, and to the creator of C++, is it now too late to address it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论