Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Is C++ Ready For The Desktop? 9

Posted by timothy from the do-bears-dream-about-people? dept.
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."
This discussion has been archived. No new comments can be posted.

Is C++ Ready For The Desktop? More

Is C++ Ready For The Desktop?

Comments Filter:
  • 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.
  • CORBA CORBA CORBA!

    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.

  • KDE and Windows COM (Score:4)

    by Snowfox ( 34467 ) <snowfoxNO@SPAMsnowfox.net> on Wednesday May 09, 2001 @02:44AM (#236522) Homepage
    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.


  • 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.

  • The need to break everything into components - who expects to understand the whole thing?!
  • ... and I believe the most common DLLs have already been built to unique addresses to minimize the need for relocation/redundant copies.
    I haven't actually checked the address spaces of my MS DLL's (MFC42.dll, etc.) to see if they're different, but I believe they are since the Visual C++ documentation recommends doing that.

    There's only one little problem with that method, though... There's nothing to prevent anybody else from assigning their DLL base address to one already used by a very higly used library, i.e. the MFC runtimes.

    In fact, I'd be willing to bet that most of the ActiveX controls, DLL's and such compiled under Visual Basic keep the default base address.

  • 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

Slashdot Top Deals

"If I do not want others to quote me, I do not speak." -- Phil Wayne

Close