SUBMISSION: New Library for kdesupport: indexlib

[Koos Vriezen]

David Johnson wrote:

> On Tuesday 14 June 2005 01:08 pm, Koos Vriezen wrote:
[..]
> 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.

I've not studied the library closely enough to judge on this. But it
makes sense that things like shared_ptr will be used in other parts as
well.
I recall additions to the standard that were based on boost (somebody
with a link?). Anyhow, that doesn't mean they exacly copy it of course.

> > 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.

Yes, we have Qt signals and QuardedPtr but that only works for QObject
as you probably know. Maybe the part of KDE sources that I read, happen
to be the only onces where QObjects are often out of the question due to 
its size, but that is exactly what I meant with a nice addition.

Btw. not all of Qt signals shines. Take for instance the cross namespace
troubles. And, what I've been fighting in my code, the connection
tracking. If a slot can be connected to different signals from different
objects than it's hard to disconnect w/o extra administration of object
and signal, ending up in ugly switch statements (of course remember the
signal as char* would work, but that is abusing a non documented
implementation).
And here boost signal shine.

> 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.

Yeah well attached a testing source file from me some time ago. Compiled
stripped will be about 36k. But is that really a problem. Should we
abandon iostreams in favor of read(2)/write(2) and will that actually
speed up the application or just make the binary a bit smaller?
IMO, its good to have more choices (and these also don't bloat core
libs).

Koos
-------------- next part --------------
// g++ signals.cpp -o signals -lboost_signals

#include <iostream>
#include <boost/signal.hpp>

float compute_sum(float x, float y) {
      return x+y;
}

float compute_product(float x, float y) {
      return x*y;
}

float compute_difference(float x, float y) {
      return x-y;
}

float compute_quotient(float x, float y) {
      return x/y;
}

template<typename Container>
struct aggregate_values {
    typedef Container result_type;

    template<typename InputIterator>
        Container operator()(InputIterator first, InputIterator last) const {
            // resuts of the slots, note slots are executed on deference
            // of the iterator (lazy call, can quit if necessary)
            return Container(first, last);
        }
};

int main () {
    boost::signal<float (float, float), // slot prototype
                  aggregate_values<std::vector<float> > > sig; // optional combiner

    boost::signals::connection c = sig.connect(&compute_quotient); // undefined group
    sig.connect(1, &compute_product); // 1 group (order of signal call
    sig.connect(2, &compute_sum);        // 2 group
    sig.connect(2, &compute_difference); // 2 group (same group, order undefined)

    std::vector<float> results = sig(5, 3);
    std::copy(results.begin(), results.end(), 
            std::ostream_iterator<float>(std::cout, " "));
    c.disconnect(); // disconnect
    // boost::signals::scoped_connection c = sig.connect(ShortLived()); // auto disconnect
    // derive from class from boost::signals::trackable to make signal detect
    //   object destruction (typically with bind<&class::method, object>
    return 0;
}
/*
 * example, note the slot passing

class Button 
{
      typedef boost::signal<void (int x, int y)> OnClick;

    public:
        void doOnClick(const OnClick::slot_type& slot);

    private:
          OnClick onClick;
};

void Button::doOnClick(const OnClick::slot_type& slot)
{
      onClick.connect(slot);
}

void printCoordinates(long x, long y)
{
      std::cout << "(" << x << ", " << y << ")\n";
}

void f(Button& button)
{
      button.doOnClick(&printCoordinates);
}
*/