[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    Re: KDE/kdepim/kleopatra/crypto
From:       Marc Mutz <marc () klaralvdalens-datakonsult ! se>
Date:       2008-02-19 7:26:27
Message-ID: 200802191026.54981.marc () klaralvdalens-datakonsult ! se
[Download RAW message or body]

On Tuesday 19 February 2008 05:17, Aaron J. Seigo wrote:
> On Monday 18 February 2008, Ingo Klöcker wrote:
> > Sure, but I claim that all KDE developers will be able to understand the
> > Q_FOREACH version at first sight because similar constructs are used
> > everywhere else in KDE.
>
> +1
>
> > OTOH, I further claim that almost all KDE
> > developers will have to consult the STL documentation in order to
> > figure out wtf the STL version does.
>
> probably, yes
>
> > Anyway, it's your code.
>
> yes
>
> > You will  have to maintain it.
>
> not forever. eventually we all move on one way or another. leaving code
> behind that is obfuscated for the masses is just disrespectful of those who
> will come after us.
>
> this is also why we do {}s on every conditional.
>
> Marc, you may be brilliant. those who come after/around you may not be
> brilliant in all the same ways.

Such comments deeply offend not only me, but every single KDE developer, 
because they assume that KDE developers in general are too dumb to understand 
anything that they can't look up in QtAssistant, not even _standard_ C++(0x).

KDE is a C++ project. At least Kleopatra is. If one doesn't like C++, or one 
refuses to learn it's standard library, one should write his apps in PyQt or 
GTK.

And if I can't expect someone to understand the very well-documented and 
widely publicized boost libraries that went into C++0x, then how in the world 
can I trust him to fix bugs in the delicate interaction with 
less-than-perfectly documented C libs such as gpgme. Guess what. I can't. But 
I won't rewrite gpgme in Qt because of this. It's the _standard_ way to do 
things with gnupg. Using bind() is the _standard_ C++0x way of defining small 
functors in-place, and you don't really want me to use the standard C++98 way 
of doing this. The C++ world does _not_ only consist of Qt.

Oh, btw, Qt 4.4 comes with qBind(). Eeek. Let's revert qt-copy to 4.3!

Regarding my dislike of Q_FOREACH: For one, it only works on immutable 
containers. Second, to get the comparable performance to an STL algorithm, 
you need to say const Foo & in the first parameter to avoid the copy ctor. 
Now, _that_ doesn't help readability. Third, it can only iterate over the 
whole container. And last, it copies the container, and I don't trust it to 
do so _only_ when the second argument is an rvalue. STL containers, as you 
know, are required to implement deep copying, so using Q_FOREACH on them is 
often is a premature pessimization. In my mind, everyone who touches a 
Q_FOREACH should be aware of these issues. I don't like to constantly need to 
think about these issues, so I use the well-defined and never-to-be-changed 
STL containers and algorithms instead. The knowledge gained in learning them 
has much higher half-life than learning copycat Qt APIs.

That said, I probably wouldn't have written said std::transform from scratch. 
As I mentioned in the mail you both so strongly felt the need to reply to (if 
not to read), this expression came into being through code evolution. I 
_probably_ wouldn't write such a construct from scratch. Probably. That 
doesn't mean, though, that I actively go around in my code and remove these 
again, unless they cause (technical) problems, which this one did.

Thanks,
Marc

-- 
Marc Mutz -- marc@klaralvdalens-datakonsult.se, mutz@kde.org
Klarälvdalens Datakonsult AB, Platform-independent software solutions

[prev in list] [next in list] [prev in thread] [next in thread]