Slashdot Mirror
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."
← Back to Stories (view on slashdot.org)
So what are you trying to say? Do you think it's bad Linux has grown so much? I certainly don't.
And, I think you're only partly right. It is true the core parts of a Linux distribution are very complex pieces of software: the kernel, the X server, the C compiler, etc. However, there are many, many nice little apps that are perfectly understandable to the average hacker. You'll just have to put your ego aside.
This is your sig. There are thousands more, but this one is yours.
pur-ty picturez.
cpeterso
Is CORBA implemented with directly callable methods, or must all calls be made via sockets? If it works purely via sockets, there's huge overhead, and a fundamental programming paradigm shift if resources need to be retained by the CORBA server object.
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.
Yes, some of the toughest problems in the open source world require you to climb an Everest scale learning curve. Mozilla and OpenOffice come to mind. Those two are attempting to Be-all Do-all Doo-dad of the variety one has come to expect from a Large software vendor.
That said, however, Waldo's performance analysis of ld.so for KDE app startup is valuable. The details and guts of the problem have been exposed to the light; it brings a potential solution that much closer to reality. It helps to focus attention where it needs to be.
Finally, it poses a specific challenge to be addressed. Source code for all relevent pieces are open for all to see.
Anyone that addresses this challenge effectively will be recognized for the accomplishment. Over time, this C++ VFT address issue will become more important.
"Provided by the management for your protection."
The need to break everything into components - who expects to understand the whole thing?!
This article shows that those with an inordinate amount of time to spend on a product are the only ones who can truly 'give back' to the Open Source community. The technical detail and aptitude shown in the article is pretty deep, but who could have come up with so good a report? Only someone paid to develop the product.
The more Linux moves towards a fully functioning OS with all the bells and whistles, the less its source remains accessible to the common hacker. It takes time to work on something as intricate as a runtime linker, and it is unlikely that someone with a job outside a dedicated Linux company would have the time to gainfully produce ideas, concepts, and code for the Linux system.
What made Linux a fun hacker's OS was the ability to wade through code and tweak to your heart's content. With all the growth that Linux has achieved, that is no longer possible.
Dancin Santa
Repeat after me (whined to the sound of "Marcia Marcia Marcia!"):
CORBA CORBA CORBA!
--Blair