Nach 17 Jahren ist es zu spät, C ++ Runtime-Erweiterbarkeit zu beheben? [geschlossen]

Der Zeitrahmen von 1992 bis 1993 war für C ++ entscheidend und verhängnisvoll.

Im '92 / '93-Zeitrahmen habe ich an einer Plugin-Architektur für Aldus PageMaker gearbeitet, die in C ++ programmiert wurde. PageMaker basiert auf einem C ++ - OOP-Framework namens VAMP, das die Portabilität zwischen Mac OS und Windows unterstützt.

Wir haben also versucht, die Funktionen von C ++ zu verwenden, um eine Plugin-Architektur zu erstellen. Dies erwies sich aufgrund des sogenannten "spröden Basisklassenproblems" als sehr problematisch für C ++ - Klassen.

Ich fuhr fort, eine Arbeit zu schreiben, die in Zeitschriften veröffentlicht wurde und die ich bei OOPSLA '93 in einem Reflexions-Workshop vorstellte. Sie können das PDF-Format des hier vorgestellten Papiers lesen:

zeitunabhängige virtuelle Memberfunktion, die für C ++ evolvable Klassen verschiebt (Klicken Sie auf die Seite nach unten und klicken Sie auf Anzeigen oder Herunterladen )

Auf einer Usenix-Konferenz in Portland nahm ich auch Kontakt zu Bjarne Stroustrup auf und ging mehrere Monate mit ihm ins Gespräch, wo er sich für das Problem des Problems der Sprödigkeit der Basisklasse einsetzte. (Leider wurden andere Probleme zu dieser Zeit als wichtiger erachtet - zum Beispiel RTTI durch Genehmigung zu betreuen.)

Microsoft stellte zu dieser Zeit das COM / DCOM-System für die Windows-Plattform vor, das als eine brauchbare Lösung für das Problem angesehen wurde. C ++ könnte als eine Implementierungssprache für COM über abstrakte Klassen verwendet werden, die zum Definieren von COM-Schnittstellen verwendet werden.

Allerdings scheuen Entwickler heutzutage COM / DCOM - und speziell ActiveX, das auf COM basiert. (1994 habe ich bei Microsoft gearbeitet und dort C ++ und COM / DCOM für den Rest des Jahrzehnts verwendet. Ich kam zu dem Schluss, dass die Technologiekombination eine definitive Sackgasse war. Ich verweise auf diese Erfahrung hier: Effektive unternehmensweite verteilte Softwaresysteme aufbauen )

Im Gegensatz zu all diesen frühen C ++ - Vorgeschichten hat Steve Jobs Firma NeXT in den frühen 90ern eine Plugin-Architektur mit Objective C entwickelt, die integraler Bestandteil des NeXT Step-Frameworks war. Heute lebt es in Mac OS X auf Apple Computern und wichtigen Plattformen wie dem iPhone.

Ich reiche Objective C ein, um das Plugin-Problem besser zu lösen.

Die Champions von Java werden Faktoren wie die Garbage-Collection als Gründe nennen, warum sie produktiver ist als C ++. Ich werde das nicht bestreiten, aber Objective C hatte bis vor kurzem noch keine Speicherbereinigung mit 2.0. Auf dem iPhone ist die Müllsammlung immer noch nicht verfügbar. Nichtsdestoweniger ist die Architektur des OS X-Plugins durchaus brauchbar - ganz und gar aufgrund der Vorzüge von Objective-C-Stil von OOP gegenüber C ++ - OOP.

Interessanterweise wurde Java verwendet, um die pervasivsten Plugin-Architekturen zu erstellen, die für jede Plattform oder Softwareentwicklungs-Community existieren. Die Eclipse-IDE-Plugin-Architektur, die mittlerweile so legendär ist, wie es solche Architekturen tun, beinhaltete vor einigen Jahren die Equinox OSGi-Modul-Management-Schicht. J2EE-App-Server unterstützen seit zehn Jahren eine Plugin-Architektur für EJBs. Heutzutage haben alle namhaften J2EE-App-Server OSGi ebenfalls integriert, um Runtime-bindbare Module zu verwalten. Das Spring Framework und seine Laufzeit-bindbare Einheit von Spring Bean hat J2EE übertroffen - hauptsächlich aufgrund der Stärke seines Systems zur Verwaltung der Bindung von Spring Bean.

Die Java-Gemeinschaft versucht immer noch, einen offiziellen Modul-Management-Standard zu definieren, aber die Java-Plattform unterstützt Software-Architekturen, die Plug-in-Funktionen umfassender als jede andere Programmierplattform enthalten.

Trotz der Schwächen von Java als Sprache im Vergleich zu C #, und dass .NET bereits eine stärkere Modulimplementierung in seinem .NET-Assembly-Standard hat, ist Java immer noch Lichtjahre in Bezug auf alltägliche Softwaresysteme, von denen einige verwendet werden Form der Plugin-Architektur. Seltsamerweise weiß die Java-Gemeinschaft nicht einmal bewusst, dass dies der Grundstein für ihren anhaltenden Erfolg als Unternehmensentwicklungsplattform ist.

Ich persönlich halte das Problem der spröden Basisklasse von C ++ für den fatalsten Fehler.

Nachdem 17 Jahre vergangen sind, seitdem dieses Problem für die C ++ - Community und für den Ersteller von C ++ hervorgehoben wurde, ist es jetzt zu spät, um es anzusprechen?