--nextPart4446092.RyDl5xJY0i
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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.=20
> > > 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 anythi=
ng
> 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=
=20
know stl, we certainly wouldn't have as many developers.  Roberto did this=
=20
programming in stl so he could learn it better (iirc).

> 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 bui=
lt
> 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=20
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=
=20
old code

But the point is moot anyway, because Roberto had already given me his=20
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=
=20
small group of developers (basically just roberto + a few other small=20
contributions iirc).  Anything which makes it easier for others to contribu=
te=20
is not a waste of time in my opinion (many kdevelop3 contributors will=20
agree).  Thus, I will likely tackle kdevelop-pg at some point, to make it=20
easier to implement those things that Roberto identified as being deficient.

Cheers,
Hamish.

--nextPart4446092.RyDl5xJY0i
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBETW8LH8BtnSmIlUYRAliHAKDl7NESajDqLZsm/n+trd26kUZSHACgihj/
duybJIX1i8tKjd7z2NB2nlo=
=Bmv3
-----END PGP SIGNATURE-----

--nextPart4446092.RyDl5xJY0i--

_______________________________________________
KDevelop-devel mailing list
KDevelop-devel@barney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel