Google Summer of Code 2006 Project proposals

[Richard Dale]

On Tuesday 25 April 2006 01:36, Hamish Rodda wrote:
> On Tuesday 25 April 2006 02:34, Kuba Ober wrote:
> > On Monday 24 April 2006 05:58, Roberto Raggi wrote:
> > > Hi Hamish!
> > >
> > > On Wednesday 19 April 2006 10:55, Hamish Rodda wrote:
> > > > The approach being taken by active developers is our internal parser,
> > > > and we are confident that with time it will get up to scratch.
> > > > Currently I'm refactoring it from stdlib to qt, to make it more
> > > > accessibile to myself and other developers for hacking.
> > >
> > > wow Hamish! rpp2 is just great :-) please Hamish rename it in rpp (or
> > > preprocessor?) and remove the old rpp code. We don't need crap-stl code
> > > now that we have *cute* Qt code ;-)
> >
> > 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.

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.
> > 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
>
> But the point is moot anyway, because Roberto had already given me his
> blessing to port it, and we're both much happier with the outcome.
>
> kdevelop3 suffered from its c++ parser being only maintainable by a select
> small group of developers (basically just roberto + a few other small
> contributions iirc).  Anything which makes it easier for others to
> contribute is not a waste of time in my opinion (many kdevelop3
> contributors will agree).  Thus, I will likely tackle kdevelop-pg at some
> point, to make it easier to implement those things that Roberto identified
> as being deficient.
Yes, I agree.

-- Richard