Google Summer of Code 2006 Project proposals

[Kuba Ober]

> > > I don't think that porting from C++ containers to Qt containers is
> > > anything but a waste of time. C++ coders are supposed to know standard,
> > > now decade+ old library that comes with C++. How porting it to a
> > > less-standard, toolkit-specifit containers will make it more accessible
> > > is beyond me. Anyone who codes in Qt is supposed to know C++, right?
> >
> > C++, yes, but not necessarily stl.  If every kde developer was required
> > to know stl, we certainly wouldn't have as many developers.  Roberto did
> > this programming in stl so he could learn it better (iirc).
>
> I will be writing a Ruby parser using the rpp parser, and it makes it a lot
> easier for me if it only uses Qt containers and the Qt library. I'm not
> primarily a C++ programmer, and don't like it very much. I find the Qt and
> KDE libraries about the only C++ code that a normal human, such as myself
> can work with, as they are designed for usability over 'cleverness' with
> templates. All the stl and templates stuff is far too complicated.

Templates are a standard part of the language. Their use is not "cleverness", 
it's just an everyday thing (or should be). Both KDE and Qt have evolved from 
code that had to compile on compilers where template support was picky at 
best, and plain broken otherwise. It's true that people have every right to 
sticking to what works now, but it's just backwards to me not to learn new 
tools and techniques as they become available.

It's unfortunate that use of templates is considered as something inhuman, 
tricky or otherwise non-everyday. It's saddening, but I find this attitude 
and its effects prevalent among the people I was recently interviewing for a 
C++ developer position. I somehow don't buy an argument the someone calls 
him/herself a "C++ programmer" yet has no clue about a large part of the 
language itself :( That's akin to saying that you're very good in English, 
but can only speak in present simple.

> If you carry Kuba's argument to its logical conclusion we shouldn't be
> using Qt signals and slots either because there is the Boost Signals
> library.

Boost signals library and Qt's signal/slot mechanism are similar only on the 
surface. They are two wildly different implementations of the same concept, 
and provide differing functionalities. Boost signals have to live with lack 
of introspection in C++, or rather, introspection being awkward to do by 
hand. Qt added an extra compilation step which gives it way more power. I'm 
not arguing for dropping Qt's signal/slot mechanism nor abandoning moc, and I 
can hardly see why it would be inferred from what I said before.

> > > I don't think that there's anything lacking in the C++ library
> > > documentation nor implementation departments, so please tell me how
> > > moving from a container library that's part of the language standard,
> > > and is built upon in numerous boost extensions, to a container library
> > > that comes with Qt is good?
> >
> > A few reasons in this case:
> > 1) The use of template classes made the code difficult to read
> > 2) The use of iterators (in particular, the frequent copying and
> > assignment of iterators) made it difficult to follow the program's logic
> > 3) I was unable to locate bugs that had gone unfixed for some time with
> > the old code

Rephrasing: you're inexperienced. "Difficult to read", "difficult to follow", 
"unable to locate bugs": it's all true in your case, and that's about it. I 
don't mean "inexperienced" in a derogatory sense. It's merely an observation. 
There are people who read template code just fine, and they are no 
better/worse than you, of course, so don't get me wrong. It's just that they 
have learnt the "template cleverness".

I do agree that whoever writes the code has got the ultimate say, and whatever 
tools he/she wants to use are his/hers, even if those tools aren't the newest 
ones. I just try a little advocacy for people to learn new stuff. Keep up the 
good work!!

Cheers, Kuba