While I have stopped using KDE almost two years ago, I don’t hate KDE per-se… I have trouble with some of the directions KDE has been running in – and I fear the same will happen to GNOME, but we’ll see that in a few months – but I still find they have very nice ideas in many fields.
Unfortunately, there is still one huge technical problem with KDE, and KDE-based third party software (well, actually, with any Qt-based software): they are still mostly written in C++.
Now, it’s no mystery that I moved from having a liking at that language to hating it outright, preferring things like C# to it (I still have to find the time to learn ObjectiveC to be honest). One of the problems I have with it is the totally unstable nature of it, that is well shown by the number of problems we have to fix each time a new GCC minor version is released. I blogged last week about GCC 4.5 and what actually blew my mind out is what Harald said about the Foo::Foo() syntax:
The code was valid C++98, and it wasn’t a constructor call. In C++98, in every class
Harald van DijkC, the nameCexists as both a constructor and a type name, but the constructor could only be used in certain contexts such as a function declaration. In other contexts,C::Csimply meansC.C::C::C::C::Cwas also a perfectly valid way to refer to classC. Only later did there turn out to be a need to refer to the constructor in more contexts, and at that pointC::Cwas changed from a typename to a constructor. GCC 4.4 and earlier follow the original C++ standard in this respect, GCC 4.5 follows the updated standard.
Now, I thank Harald for clearing this up, but even so I think this aliasing in the original standard was one of the most obnoxious things I ever read… it was actually making much more sense to me that it was an oversight! Anyway, enough with the C++ bashing for its own sake.
What I would ask the upstream KDE developers is to please set up some way to test your code on the newest, unstable, unusable for day-to-day coding upcoming GCC branches. This way we would avoid having the latest, very recent, release of a KDE-related tool to fail the day the new GCC exits beta status and gets released properly. I’m not expecting that you fiddle to make sure that there are no ICEs (Internal Compiler Errors) caused by your code (although finding them will probably help GCC upstream a lot), but at least make sure that the syntax changes won’t break as soon as a new GCC is released, pretty please.
Of course, this kind of continuous integration, even extended to all of the KDE software hosted by KDE.org is not going to be enough as there are huge numbers of packages that are being developed out of that… but it would at least give the idea that there is need for better CI in general in FLOSS!
Well asking the KDE people to move away from C++ is like asking to rewrite their whole stack yet again so chances are limited ;)You are asking for a shitstorm of flames here, my friend 😉
Eh? Sorry but I *never* asked that. I just asked for them to set up a Continuous Integration framework running on the _latest_ code from GCC to make sure their syntax will be valid with the next release of the compiler as well as the current one…
Just because Gentoo has trouble with this doesn’t mean people should abandon the technology.Qt/C++ is miles ahead of Gtk/C. I’m developing on both, and the Gtk/C combination is not very productive or maintainable. Qt/C++ is pretty much the best thing to ever happen to Linux and when I see comments like yours, I’m left speechless every time.
And I’m speechless you don’t read the fucking article.
@RealNCWell “adopting a Continuous Integration framework” doesn’t really mean “people should abandon the technology”.And for the record i don’t think that gentoo is the only distro facing this kind of ggc related issues on software, if you got a binary package for your favorite distro, someone fixed it to support the currently adopted gcc.Flash news:some GCC upgrades break binary compatibility O_o
while i agree with you that there should be some infrastracture for what you’re asking for, i don’t think it is a good idea to raise it on your blog alone.
You should clarify better your position against c++, as it’s written it seem the main reason why c++ is bad is it’s implementation by gcc.P.S. I do agree whit this : “Qt/C++ is miles ahead of Gtk/C.”P.P.S. full llvm support in gentoo would be funny, full intended as selectable by gcc-configP.P.P.S. after few years the file dialog of firefox and other still sucks 😉
LLVM is a beast on its own and I rather not go there yet.As for my position against <notextile>C++</notextile> do you really read my position about @C::C::C::C@ as being related to GCC implementation? It’s in the frigging standards, for fuck’s sake! And I “wrote about it”:https://blog.flameeyes.eu/t… more than once anyway.
Diego, I’ve been running GCC 4.5.0 since it came out in tandem with KDE 4.4.x. What problems did you experience? I haven’t had any.
I really do enjoy your views and thoughts on current coding and testing practices.Your blog posts are written rather well in the sense that you do not just complain about the issue that I have seen many others do. You actually present the issue and offer solutions. More developers should follow suit.
I am very surprised that you blame particularly KDE in connection with gcc upgrades. In fact, my experience in the previous gcc upgrades was always that KDE compiled with newest gcc without problems (including gcc-4.5 from the very first day with the exception of -flto which however breaks about 50% of all packages). Usually, it is C projects which break after a gcc upgrade (with gcc-4.5 emacs breaks, for instance; with gcc-4.3/4.4 most breakage of C and C++ was caused by the library cleanups; only a few C++ related changes were necessary after the declaration of strcpy was fixed in gcc-4.3). KDE was always the piece which never had such problems (or perhaps the developers had fixed them even before the newest gcc was released).
Your example against C++ based on minor compiler versions is not very honest IMO. There is bad written software all over the place no matter the language its written in. There will always be developers who think they can outsmart the compiler by bending the rules which eventually breaks things with the next stricter compiler version. Plain C is definitely no exception here.Granted, C++ tries to hard to scratch everybody’s itch. Resulting in fuzzy or bad implemented standards and the so hated unlimited (good or bad) choices one could and has to make when writing a C++ program. However, it has taken over 10 years, a massive amount of clueless C++ rants and a big corporate interest to *finally* become a moving target again, having a revised standard and some acceptance by the free software community. Like any moving target this involves reevaluating previously established standards and adjusting when needed. So this breakage is all for the best. People nitpicking on these kind of breakages are usually just spreading FUD.And when it comes to standards, are you aware most of the GNOME stack still demands C89. How can that platform ever move forward when everything other that C is distrusted or results in massive flame wars.
The fact you would advocate C# makes me question whether you truly operate in the best interest of FOSS software. Not only do you make derogatory comments aimed at one of the best desktop environments for power users, but you prefer a patent minefield of a language that is less efficient and Windows-based. (Redundant, I know.)While KDE has its own issues, it’s made great strides in usability, something I do not feel from GNOME or GTK. I know one of the top developers and I have not seen a more to-the-point, passionate and enthused man who wants to bring an ever-evolving desktop to any and everyone.Feel free to write scathing criticisms in your blog that are devoid of real argument while not appropriately informing KDE staff of your discomfort.Meanwhile, I enjoy being productive.
@Dann you are wrong, C# isn’t a patent minefiled language, surprise, surprise, it’s an open standard approved by Ecma (ECMA-334) and ISO (ISO/IEC 23270); instead is the .Net framework the patented one (which isn’t been mentioned by Diego in his post)please, next time don’t write non-sense comments because you’re only doing FUD.
When a new release of GCC happens and there are KDE build problems, they get reported and fixed. I don’t see a problem with that approach. And the C::C::C bug should be trivial to fix in the first place.Problems with new GCC versions aren’t only C++ related. I had a log of C programs break due to missing includes. Those are also trivial to fix.On a similar note, binary compatibility isn’t a huge problem. I’m building my Qt applications on Debian Lenny with its outdated Qt and GCC, and they run just fine on latest, bleeding-edge ~amd64 Gentoo.
@realNC: the problem of the missing includes comes from glibc and not from the gcc compiler
Excellent article. I myself as a coder do like C++, and consider it’s in some way like the autotools : extremely perfectible, but much better than anything else that exists for many, many situations (not all) : either you like it or you don’t understand it, in some way, that is my opinion (yes, yes, preprocessor + templates metaprog + STL + exotic libs may become ugly, sometimes… when it’s ugly, coder did not understand the language and the tools 😉 ). That OF COURSE does not mean GCC may be coded in C++… I fully agree with your previous post about it. G++ ABI changes far too often (each version ?) and I do not want to have to emerge -e world for any GCC update, even forgetting G++ bugs and ICEs, that remain too numerous. In fact (no troll here) MS’s cl.exe + the brave old STLPort are often a better way to write good C++ than G++ and its standard STL. But KDevelop 4 has arrived, and first use (no time for more by now) looks really impressive, all hope is not lost…BUT, to some commentors who seem to live in another reality… C++/Qt are in my opinion NOT better than C/GTK+ (let’s not even speak of gtkmm) : a preprocessor (moc) was a terrible idea, a real monstrosity, and when you fall into trying to debug it, it’s just hell. Qt4, alas, went far on the right way (templates) but did not finish its way and get us rid of the moc abomination… C#, in my opinion, is even worse. ILasm is even less easy to debug than moc-ified code. And slower to execute. I never liked KDE (no troll, I think it’s an excellent desktop… for other people !) and I am getting more and more deceived by Gnome and, for my work, do not want to switch to more “amateur” or “exotic” desktops, since I am trying to put FLOSS desktop into the real world (even XFCE is extremely hard to sell to MSWord-intoxicated-blond-big boobs-low IQ secretaries. A chance Windows 6.0+ and MSOffice 12+ are so long to see their bad ergonomy accepted by lusers).About CI… Diego, your long experience with your tinderbox may look precious here. Too bad you miss the time and material, huh ? 🙂 Maybe it’s time for a Gentoo-derived, tinderbox-oriented crapware compiler meta-distribution, with overlays preconfigured with experimental (probably VCS-extracted) build toolchain… Preferably to be run in a virtual machine. No auto-bugging, but at least auto-preparing bug reports to maintainers/packagers should be useful… I will try to see if the idea is doable this week-end or the next ! 🙂 Diego, if you have some tinderbox code that you think may be useful for it, your generosity or better, your indications are welcome. I hate to be “visible” but THAT would be useful, and to me first.As often, I have to say I agree with much, and that your “rant” is written with some intelligence and experience. Now let’s try to make it useful…
Now, it’s no mystery that I moved from having a liking at that language to hating it outright, preferring things like C#See, with comments like this, youre gonna leave yourself open to questions about your sanity.But damn, troll for hits and the FLOSS world will respond.HVE above makes the point I was going for so Ill just a Me Too to his post.We develop with both Qt/C++ AND Gtk/C at workand Gtk/C is an absolute pain in the rump (I work in the mobile field and QT is amazing, always improving and after time became Free in all sense of the word.) compared to the QT++.On both principle and especially practicallity (since we use the best language for the jobs and arent beholden to just one) though, C# is a non-starter in our company.I asked this question about upcoming GCC versions and any problems they bring to one of our dept heads and he said “its part of dev work, that’s all. And the problems overall are very minimal and easily fixed. In no way does it affect productivity. If it did, THEN it would be a problem.”This isnt a bad blog but the whining and bitching and black-white atittude is more conducive to driving page hits than it is to collaborating with free software projects. Too many hotshots think they know better than everyone else and worse, they get angry, insulted and demeaning towards others who dont share their idea. “I dont agree, ergo, youre a moron.”The word is full of egodriven developers who might have good ideas but dont know how to formulate them in a coherent and presentable fashion.In other words, if you were to approach a project with that attitude, youd probably get told to calm down a bit and breath through your mouth.You might get away by calling your buddies braindamaged but saying that to skilled developers will result in a predictable outcome.Of course, most code geeks have teh social skills of swamp rats so getting community members to work together will always be a challenge as will herding people who might have good ideas but lack the social skills to work in a non-hierarchal organization.I know venting in a blog isnt the total of a persons personality but I also know the stereotype you fit perfectly too.I also know that if you are just bitching about this in a blog and not taking any steps communcating this through the proper channels, then this is all rhetorical.
@equilibrium:> The problem of the missing includes comes from glibc and not from the gcc compilerBoth, glibc and gcc had cleaned up their libs, each causing different kind of missing includes.
I think you misdirected your request Diego.It really looks like you wanted to write anything remotely related to KDE and couldn’t find anything interesting to stick to.I have better idea. Instead of asking KDE developers to maintain gcc 4.5-powered buildbot to prevent Gentoo testing boxes from breaking, unmask gcc-4.5.0 in tree so that it actually causes Gentoo testing boxes to break and fullfill their purpose (to provide testing platform).So that I can run into this problem just having ~arch chroot and make use of my KDE commit access for instance.Also let me remind you that you’ve filled some gcc 4.5 related bugs without providing any build.log and you expect those things to be fixed.People start to forget what’s the purpose of ~arch.It’s *testing* subtree of portage. And it’s supposed to be broken.Unfortunately many developers are more interested in keeping ~arch working and arch is getting outdated as a consequence.Also the nature of ~arch in Gentoo (it’s pretty much working very well, sometimes better than ‘stable’) distracts users from actually using arch, which otherwise is supposed to be ‘the one’ to be used.
Maciej, you _really_ think users will like to have a buggy compiler in ~arch? Testing or not, it shouldn’t be _unusable_, it should be at most _unstable_.As for missing logs, you might not know but filing over 200 bugs in a day, sometimes the logs might not make its way through. Rather than bitch, just ask me to attach it, I have them around._Update: just because I care I looked at the list of open GCC 4.5 bugs… there was exactly “one”:http://bugs.gentoo.org/show… that was missing the log… and it wasn’t even assigned to KDE.Oh sorry I forgot, you don’t give a fuck about stability or QA… _or, as it happens, of the effort spent by your colleagues._
If compiler is buggy and produces invalid code or dies in the process, it should be masked. If compiler causes stuff to miscompile – shouldn’t be masked. Now, I don’t really know what’s the case with 4.5, but I suppose if they marked it as stable release, one shouldn’t expect it to have broken code generator or die randomly or I’m being delusional?As for not giving the shit about unit tests in packages, you’re right – I don’t care as in my opinion running unit tests in ‘leaf’ products (applications) is solely upstream developers’ job. And if they don’t care about making unit tests work, why should the packagers?As for my sense of QA, you certainly have yet to make some research before forming an authoritative opinion about me.As for subtitlecomposer – not always bug asignee is de-facto maintaner. I didn’t mean to be bitching about that bug as I don’t really care for bugs caused by masked packages.Anyway subtitlecomposer is 3rd party application.I don’t recall any KDE Software Compilation (or formerly KDE Release) gcc4.4 or gcc4.5 related issues that haven’t been fixed already in trunk before you run into them in tinderbox.But this is maybe because KDE developers actually often use experimental gcc versions already (I’m not sure what version is compiling http://developer.kde.org/~d… though)Imho you should really stop bothering with filling bug reports related to miscompilation caused by newly introduced compiler in ~arch subtree or just misompilations in ~arch.Because it’s not important.Maintainers will run into such miscompilation problems anyway and will fix them as they appear in ~arch.It only makes you waste your precious time you could spend in some otherwise pleasant way.Some people say that mixing testing and stable subtrees is ‘broken’ and not supported.It’s because they apparently have no idea how package stabilization process works.’tinderbox’ idea of full ~arch integration tests is broken by design!Why? Gentoo is distribution with rolling updates and packages being stabilized are hand picked from ~arch and integrated within existing stable environment (along with possible dependencies).Now the qustion arises – what’s the point in testing how these packages interact with full testing ~arch? The answer is NONE!If any, following tests should be run:- regression tests – ONLY within full stable arch, typical tinderbox of just chroot would fit there well, it could prevent issues like Gentoo LiveCD autobuilds failing since 8 April…- integration tests – in similar way stabilization process is performed:* stable system as a base* picking packages or package sets for tests along with their possible dependencies (highest version visible, if not visible within stable arch, then highest visible within testing arch or some other algorithm)* testing whether it works or at least compiles so that stabilization process is formality.Comments?
Why are you getting so agitated? (Note that I didn’t say “so fucking agitated”.)There’s always a chance that a new GCC release will break existing code, both C as well as C++. Both runtime as well as compile-time. GCC 4.5 being in ~arch doesn’t mean it’s unusable. It’s not unusable. I have it installed and it works just fine, but my gcc-config default is still 4.4.3 because some packages will not build with 4.5.What else is the point of ~arch if not for testing this out? I find packages that don’t build with it and I report them upstream. If I have time to fix them myself, I do and send patches upstream. What is it about GCC 4.5 that makes it so different then previous releases breaking C code other than this time around it breaks C++ code?”Unstable but not unusable.” What does that mean? That it’s unstable and crashes but still usable?
@RealNC:I can understand Flameeyes’ agitation perfectly well. “Unstable” is being run by many people (including myself) and just shoving stuff in there without at least basic checks is more than just rude, it’s dumb.People use ~ARCH because while packages might have bugs for corner cases in general it is very usable. Those bugs can then be reported and fixed so that the few people they concern can have their problem solved, without bothering the general public that didn’t even have a problem.Shoving completely untested code into ~ARCH means that at some point you’ll break many people’s installations, and not just inconvenience a few. The bugtracker gets more spam and complaints than needed and you piss off users.This is just not cool, especially when automated testing options are already available in the wild, just like for example the Tinderbox. All Flameeyes asks of the KDE people is to run automated tests on their code to find the big blocker bugs before shipping in order to not break large amounts of people’s systems. And that is not unreasonable or anything, it’s just basic courtesy.And this is not just a user complaining about user problems. If KDE implemented a testing automatism _all_ distributions would have less work, less bugs to deal with: The bugs could quilcky be fixed by the people familiar with the code instead of someone downstream. It’s a simple way to cut out the middleman (downstream) and save work for distributors.
Anyone using an unstable package should expect it to be unstable. And if this is a package from the system set (like gcc), you shouldn’t be surprised if your system is unstable.
In addition to regular nightly builds on GNU/Linux they also have nightly builds on Windows: http://winkde.org/pub/kde/p…And if I remember correctly one KDE develoepr was talikng/writing that he regularly builds with latest Oracle/Sun Studio. So it’s not like KDE developers don’t try to compile their code in various compilers. I myself use the latest GCC versions when final versions come out and so far KDE software was some of the less problematic. So I really can’t see this blog post as a lot of whining about little things. I guess every blogger, even as excellent as Diego, sometimes has a bad day. We’re all just human afterall.