Slashdot Mirror
KDE Developer Sirtaj Singh Kang Interviewed
highwaytohell writes "Sirtaj Singh Kang is a KDE developer and an official spokesman for KDE in Australia. In this interview conducted by the Sydney Morning Herald he talks about how the KDE project manages to maintain its hierarchy, where he sees KDE in the future, Linux portability issues and the relationship between Trolltech and KDE developers. The article gives a good insight into how maintainers and developers work to maintain one of the more popular window managers for Linux. Certainly worth a read."
It's not really a problem with either C++ or Qt, it's a problem with the compilers. In particular, with how compilers implement templates. For example, let's say you have the files one.cpp, two.cpp, and three.cpp. If you use std::string for each one, then gcc will compile the string class in every file that uses it. So one.o, two.o, and three.o will all have the parts of the string class that they use (ie, most of it). The linker then discards the redundant bits when the object files are linked together. Now for heavily used template classes (the STL, for example) you basically have gcc compile large parts of a template class library for each source file, then have the linker throw them away at link time. Now the alternative is already part of the C++ '98 standard. You have this thing called the export keyword. Unfortunately, none of the big compilers (g++, Intel C++, VisualC++) support it yet.
A deep unwavering belief is a sure sign you're missing something...
jokes apart, what do you think are the ways someone can contribute if he wanted to ?
Documentation. This includes writing documentation, going through the existing docs to make sure their current and cover all bases, and contributing to documentation tools.
Testing. Start using the snapshots or cvs and bang away at the daily code. Pick one application you really like (or feel needs a lot of help) and bang away at it from every direction every day. Then submit complete bug reports.
Artwork. Missing some icons for your favorite app? Make one and submit it.
Other areas to help exist as well, and are limited only by your imagination.
P.S: I already want to change the way some RPM installations work - they dont friggin create shortcuts on my start menu!
This is a distro specific problem, but that's no reason not to help out. Of course, working for free for a commercial distribution is not my idea of charity. It all depends on how big of an itch it is.
A Government Is a Body of People, Usually Notably Ungoverned
Actually export has turned out to be a sort of misfeature. Most C++ gurus have now realised that it doesn't really do what it was hoped it would do. See this - http://www.cuj.com/current/index.htm?topic=current
(Scroll down to bottom)
"Sutter's Mill -- 'Export' Restrictions, Part 2 Until further notice: the tariffs on export are too high for everyday use."
(The whole article is only available in the print version)
In fact the very first implementation of export has turned out to be a very pyrrhic victory as said by the developers themselves. Turns out that export will need some serious redisign before any of the other C++ vendors will use it. Certainly the intent was good and one needs something like export. But export as it stands today doesn't quite cut it. The basic problem. Its too complex to implement and use and it breaks some other very basic C++ rules when you use it. Also its implementers say that it would be very difficult to give the users a consistent set of rules/advice on how to use it without getting shot in the foot. So looks like we can all forget export for a while. No need to worry about GCC or others not supporting it. Lets all wait for export v2 for that. In any case the C++ comittee agrees that they did too much of an invention with that feature without having the requisite expereince inspite of C++ compiler vendors warnign against it.
The simplest way to address this is to avoid using too many different instances. The way the QObject model works, you shouldn't need a whole lot of different instances of the same template class.
If you're concerned about the compile load of template instantiations, you can always compile with -fno-implicit-templates. Sure it's a bit of a pain, but it can shave a lot off your compile times.
On another topic, who else thinks C++0x should make provisions to forward declare templatized class instances? Including all these template definitions in every header file is complete death for compilation time: #include , for example.
You already can do similar to this. Some compilers, like gcc allow you to suppress implicit instantiation. Of course, the compiler still has to parse the extra code, but it no longer has to create instances of those member functions. The compile checking on uninstantiated members is minimal.