1992年から1993年の時間枠は、C++にとって極めて重要で運命的なものでした。
'92 / '93の時間枠で、C++でコーディングされたAldusPageMakerのプラグインアーキテクチャに取り組みました。PageMakerは、MacOSとWindows間の移植性を支援するVAMPと呼ばれるC++OOPフレームワーク上に構築されました。
そこで、C++の機能を使用してプラグインアーキテクチャを構築しようとしました。これは、いわゆる脆弱な基本クラスの問題のため、C++クラスでは非常に問題があることが判明しました。
ジャーナルに掲載され、OOPSLA'93でリフレクションワークショップで発表した論文を書き始めました。ここで紹介した論文のPDF形式を読むことができます。
C ++ Evolvableクラスの時不変仮想メンバー関数ディスパッチ （ページを下に移動し、[表示]または[ダウンロード]をクリックします）
また、ポートランドで開催されたUsenixカンファレンスでBjarne Stroustrupと連絡を取り、数か月間彼と対話を続けました。そこで、彼は私に代わって脆弱な基本クラスの問題に対処する問題を支持しました。（残念ながら、当時は他の問題がより重要であると考えられていました。たとえば、承認を通じてRTTIを回避しようとしました。）
マイクロソフトはこの時点で、問題の実行可能な解決策と見なされていたWindowsプラットフォーム用のCOM/DCOMシステムを導入しました。C ++は、COMインターフェイスの定義に使用される抽象クラスを介してCOMの実装言語として使用できます。
ただし、最近の開発者はCOM / DCOM、特にCOMに基づくActiveXを避けています。（1994年に私はマイクロソフトで働き、残りの10年間はそこでC++とCOM/ DCOMを使用しました。テクノロジーの組み合わせは間違いなく行き止まりであると結論付けるようになりました。ここでその経験を参照します：効果的なエンタープライズの構築分散ソフトウェアシステム）
この初期のC++の歴史とは対照的に、Steve Jobの会社であるNeXTは、90年代初頭にObjective Cを使用してプラグインアーキテクチャを考案しました。これは、NeXTステップフレームワークに不可欠でした。今日、それはAppleのコンピューターやiPhoneなどの重要なプラットフォーム上のMacOSXで活気に満ちています。
プラグインの問題を優れた方法で解決できるObjectiveCを提出します。
Javaのチャンピオンは、C ++よりも生産性が高い理由について、ガベージコレクションなどの要素を引用します。私はそれについて異議を唱えるつもりはありませんが、ObjectiveCはごく最近まで2.0でガベージコレクションを行っていませんでした。iPhoneでは、ガベージコレクションはまだ利用できません。それにもかかわらず、OSXプラグインアーキテクチャは完全に実行可能でした-完全にOOPのObjectiveCスタイルとC++OOPのメリットのためです。
興味深いことに、Javaは、あらゆるプラットフォームまたはソフトウェア開発コミュニティに存在する最も普及しているプラグインアーキテクチャを構築するために使用されてきました。Eclipse IDEプラグインアーキテクチャは、そのようなアーキテクチャが進むにつれて、今では事実上伝説的であり、数年前にEquinoxOSGiモジュール管理レイヤーに組み込まれました。J2EEアプリサーバーは、EJBのプラグインアーキテクチャを10年間サポートしてきました。最近、注目すべきすべてのJ2EEアプリサーバーは、ランタイムバインド可能モジュールを管理するために同様にOSGiを組み込んでいます。SpringFrameworkとSpringBeanのランタイムバインド可能ユニットは、主にSpringBeanのバインドを管理するためのシステムの強度によりJ2EEを超えるまでに成長しました。
Javaコミュニティは、公式のモジュール管理標準を定義するのにまだ苦労していますが、現状では、Javaプラットフォームは、他のプログラミングプラットフォームよりも広くプラグイン機能を組み込んだソフトウェアアーキテクチャをサポートしています。
C＃に比べて言語としてのJavaの弱点、および.NETの.NETアセンブリ標準でのモジュール実装はすでに強力ですが、Javaは、何らかの形式のプラグインを組み込んだ、広く使用されている日常のソフトウェアシステムの点でまだ光年先を進んでいます。建築。不思議なことに、Javaコミュニティは、これがエンタープライズ開発プラットフォームとしての継続的な成功の基盤であることを意識的にさえ認識していません。
私は個人的に、C++の脆弱な基本クラスの問題が最も致命的な欠陥であると考えています。
この問題がC++コミュニティとC++の作成者に取り上げられてから、17年が経過しましたが、今では対処するには遅すぎますか？