1992年到1993年的时间框架对于C++来说是至关重要的.
在'92/'93时间框架中,我研究了Aldus PageMaker的插件架构,该架构采用C++编码.PageMaker建立在一个名为VAMP的C++ OOP框架上,它支持Mac OS和Windows之间的可移植性.
所以我们尝试使用C++的特性来构建插件架构.由于所谓的脆弱基类问题,这证明对于C++类来说是非常有问题的.
我接着写了一篇发表在期刊上的论文,并在OOPSLA '93的反思研讨会上发表了论文.您可以阅读我在此处介绍的论文的pdf格式:
时间不变虚拟成员函数调度C++ Evolvable类 (页面底部,单击查看或下载)
我还在波特兰的Usenix会议上与Bjarne Stroustrup联系,并与他进行了几个月的对话,在那里他主张代表我处理脆弱的基类问题.(唉,当时其他问题被认为更重要 - 例如,试图通过批准来支持RTTI.)
微软此时为Windows平台引入了COM/DCOM系统,该系统被视为该问题的可行解决方案.通过用于定义COM接口的抽象类,C++可以用作COM的实现语言.
然而,这些天开发人员避开COM/DCOM - 尤其是基于COM的ActiveX.(1994年,我继续在微软工作,并在那里使用了C++和COM/DCOM十年.我得出结论,技术组合是一个明确的死胡同.我在这里提到的经验:建立有效的企业分布式软件系统)
与所有这些早期的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 Framework及其Spring Bean的运行时可绑定单元已经发展到超过J2EE - 主要是因为它的系统强大,可以管理Spring Bean中的绑定.
Java社区仍在努力定义官方模块管理标准,尽管事实如此,Java平台支持的软件架构比任何其他编程平台更普遍地包含插件功能.
尽管Java作为一种相对于C#的语言存在弱点,并且.NET已经在其.NET程序集标准中具有更强大的模块实现,但Java在广泛使用的日常软件系统方面仍然领先一步,其中包含某种形式的插件建筑.奇怪的是,Java社区甚至没有意识到这是他们作为企业开发平台持续成功的基础.
我个人认为C++的脆弱基类问题是最致命的缺陷.
自从这个问题突显给C++社区以及C++的创建者以来已经过去17年了,现在解决这个问题已经太晚了吗？
京公网安备 11010802040832号 | 京ICP备19059560号-6 