Is C++ Ready For The Desktop?

Marko van Dooren writes: "Waldo Bastian wrote an interesting paper on the GNU ld.so linker and C++. It seems not only KDE is slow. At least now I know what the kdeinit process is for."

Comments

KDE and Windows COM

[Snowfox]

In a nutshell, the problem is that there are thousands of virtual function tables with the attendant address fixups, and the proposed hack solution - spawning every KDE app from a common process - is pretty ugly indeed.

The problem KDE is having was likely part of the reasoning behind Windows COM. COM objects are essentially virtual classes which are constructed in an optimized fashion at DLL load time, and I believe the most common DLLs have already been built to unique addresses to minimize the need for relocation/redundant copies.

There are three problems with the COM approach. First, it forces all functions to be virtual. This results in a small performance hit. KDE developers may have elected to take this route anyway, as it does introduce some extra flexibility. (Anyone know enough about KDE to comment?) Second problem - it introduces compiler dependencies. In a decade of C++ use, I haven't seen a compiler which handles VFTs differently from another, but that doesn't mean we won't - the VFT format, location and ordering are not part of the C++ specification. Third, COM is not a transparent solution. Applications would need to be altered to acquire objects through a broker. Again, I don't know KDE well enough to comment, but I very much doubt that this is currently required, or KDE likely wouldn't be having the problem it is.