After 17 years is it too late to fix C++ runtime extensibility?
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:
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?
1 Comments:
一夜聊天室女同聊天聊天室二愛聊天室苗栗聊天66k聊天69性交6k 聊天至6k 聊天館 6k6k天室6k館777貼圖區77p2 影片網77P2P77p2p277p2p本土85ccst街影城2010問題小棧0401影音視訊非會員18h漫貼圖區18p2p帳密18p2p帳號18p2p帳號密碼18r 禁小說18r禁小說18r禁影片18tw台灣18tw情色文學18us線上影片18x免費女優火辣視訊薄紗主播網友自拍露點圖18成人成人韭南籽
By
Anonymous, at 3:13 AM
Post a Comment
<< Home