SUBMISSION: New Library for kdesupport: indexlib

Koos Vriezen koos.vriezen at xs4all.nl
Tue Jun 14 21:08:01 BST 2005


David Johnson wrote:
> The problem I have with boost is that it's not a library so much as an
> eclectic collection of stuff that's on the bleeding edge of advanced
> C++ practice. I don't like "advanced C++" code because it's too hard to
> maintain. It overwhelms new programmers, and intimidates intermediate
> programmers, so that the only people who can work on the code are
> experts.

I wonder if that is really true. Every code can be intimidating if it's
written that way :). The other side is that when templates are used like
they meant to be, it saves a lot of code. As such, less intimidating
too (eg. old c++ all having their own list and string implementation, oh
wait, some new ones still have that :-).

> Other reasons: debugging heavily templated code is nasty; understanding
> error messages from heavily templated code is nearly impossible; I've
> seen no evidence beyond the self-interested advocacy that this stuff
> really will be added to the next standard; boost's heavy intertwining
> of template classes tends to cause much more "bloat" than is normal for
> templated code; and there's little cohesion in the library but a lot of
> coupling, which is the exact opposite of good OO design.

Wondering too if code bloat of templates in general is something of the
past now we have gcc-4 (the hidden-inline option).
What exactly do you mean with "opposite of good OO design", use of templates
in general or just the boost library? If the latter, then all over the
place or just some parts?

> I don't want to sound like a luddite, but sometimes boring is better
> than cutting edge, especially in a common library to be used by those
> who aren't necessarily C++/STL/template gurus.

Working on OSS is, imho, also something like educating one selves,
trying new stuff. Often in a daily job, there is not the time for that.
We should not say that it's too new or too complicated to something that
will probably the standard.
Also the shared_ptr, signals and probably more are a real nice addition
to have.


Koos




More information about the kde-core-devel mailing list