SUBMISSION: New Library for kdesupport: indexlib
david at usermode.org
Wed Jun 15 03:59:39 BST 2005
On Tuesday 14 June 2005 01:08 pm, Koos Vriezen wrote:
> 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 mean the Boost library overall. It is so tightly coupled that it's
pretty much nonsense to consider it piece by piece. Class A is
dependent upon class B and C, which are dependent on class D, E and F,
and so on. You might care less about Noncopyable, but you're going to
get it anyway because someone else decided that class Fu shouldn't be
copied. This coupling makes it impossible the ISO committee to pick
just one or two nice bits from Boost. If they use any of it they're
going to have to suck in at least half of it.
Cohesion is the other half of the bad design. Boost is an eclectic
collection of unrelated stuff. It shouldn't be one library, it should
be a half dozen libraries or more. If I want just Boost.Build to see if
it's suitable for a new KDE build system, I still have get all the
rest. Including the Python stuff. No offense to either Boost.Build or
Python, but what the heck are they doing in Boost? Is Python and a
build system going into the next C++ standard?
> Also the shared_ptr, signals and probably more are a real nice
> addition to have.
Picking on Boost.Signals, why do we need this for KDE? We already have
Qt signals and slots, and they work much better.
About two years ago I did a study on Boost.Signals and Qt signal/slots,
along with a template based signal/slot mechanism of my own. This was
for an class at work. I created a simple test application with about
half a dozen connections. I didn't keep my numeric results, but if I
recall, the Boost.Signals test application was around 70k stripped, The
Qt application only 16k stripped. This was for a simple application.
For something more complex, Boost might have bloated tremendously,
given that you will end up with a different set of classes for each
signal signature. In addition Qt was much more flexible. I didn't test
speed, but raw speed for callbacks is hardly critical for non-realtime
apps driven by user events.
Don't get me wrong, Boost.Signals is very nice. But it was made for
those living without the luxury of Qt :-)
More information about the kde-core-devel