[Qt-interest] Why do Qt collection classes not offer signals and slots?

[Hendrik Fuß]

Thanks for all your replies.

Am Donnerstag, den 17.12.2009, 17:45 +0100 schrieb Ross Driedger:
> > Hi folks,
> > I was just wondering, I thought this was the most obvious thing to 
> > have... If Qt containers supported signals and slots, you could write 
> > e.g.:
> > QVector<int> * myVector = new QVector<int>();
> > connect(myVector, SIGNAL(elementAdded(int)), this, updateList());
> > Is there a reason for the lack of signals in Qt's collection classes? Or 
> > am I missing something?
> 
> Hi Hendrick,
> 
>  From a design point of view, it would make little sense to add this kind 
> of support to a container: the idea of these classes is to make them as 
> light-weight as possible.
> 
> That said, is there anything stopping you from writing your own class that 
> is multiply derived from QVector<int> and QObject, and adding your own 
> signals?

Actually this is what I'm planning to do. It would be interesting to run
a benchmark and compare the two containers with and without signals. 

I will post results once I get there, but this will not happen until
next year.

>   I wouldn't want to use a class like this all the time, but for 
> the instances where signals are a good idea, it should be useful.

I would imagine that in a lot of GUI-related applications such signals
could really come in handy (see my example). You could just connect a
list view to a QVector and get automatic updates. To me this looks like
an interesting design perspective that does deserve consideration.

Of course, when implementing performance-critical algorithms, you will
want to eliminate any extra expense, but then again I gather from
William's reply that the Qt containers don't seem to measure up to the
standard of STL containers. If that is the case, wouldn't you want to
use a different container implementation for such a task anyway?

cheers
Hendrik