SUBMISSION: New Library for kdesupport: indexlib

[David Johnson]

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 :-)

-- 
David Johnson
___________________
http://www.usermode.org