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。）
微软此时推出了适用于 Windows 平台的 COM/DCOM 系统，被视为解决该问题的可行方案。通过用于定义 COM 接口的抽象类，C++ 可以用作 COM 的实现语言。
然而，这些天来，开发人员避开了 COM/DCOM——尤其是基于 COM 的 ActiveX。（1994 年，我继续在 Microsoft 工作，并在这十年的剩余时间里使用 C++ 和 COM/DCOM。我得出的结论是，技术组合绝对是一条死胡同。我在这里参考了那段经历：Building Effective Enterprise分布式软件系统）
与所有早期的 C++ 历史相比，Steve Job 的公司 NeXT 在 90 年代初期使用 Objective C 设计了一个插件架构，这是 NeXT Step 框架不可或缺的一部分。今天，它在苹果电脑和 iPhone 等重要平台上的 Mac OS X 中充满活力。
我提交了启用 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 年，现在解决这个问题是否为时已晚？