A Very Short Note on Why C++ Is Not Suitable for Plug-In Architecture

Plug-in architecture is where reality meets textbook and language purity. It's a practical problem because:

1. You probably own the architecture, but you don't have control over others who develop the plug-in's
2. Your project is evolving, their projects are also evolving.

Following 1. and 2., the logical next step would be coming up with a design that keeps both parties in sync with an agreed "contract" (protocol, interface, whathaveyou). Unfortunately:

1. Even the "contract" itself can evolve
2. C++ is notoriously bad at keeping up with evolving contracts. It has the notorious fragile base class and fragile binary interface problems. In some extreme cases, you can't even use different versions of the same C++ compiler and toolchain to build the different parts of a system under the same contract!

C++ is not alone in this, although C++'s problems are the most glaring given its popularity as a system software language and its promise to be such a language. Unfortunately, plug-in architecture, or anything dynamically loaded, involves system components beyond language features (its problem domain lies somewhere in the middle between operating system and software architecture design). This in turn explains the unfortunate reality why C is still the real language for system software, especially system software libraries, because C is the only language that has such a thin and straightforward application binary interface (ABI) for all seasons and all purposes.