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

[BOUCARD Olivier]

I would like to add that Qt containers are used to store data not manage data.
For me there is a conceptual difference between storing data and managing data.
This is the manager class which has signals/slots, because this is this class which knows the business.
A storing class job is just to optimize space and operations on data like inserting, deleting, updating, finding, iterating, ...
So a manager class uses a containers to give a sens to the stored data.

Regards,

Olivier.




________________________________
De : Hendrik Fuß <fuss at molecular-machines.com>
À : Ross Driedger <ross at earz.ca>; qt-interest at trolltech.com
Envoyé le : Ven 18 Décembre 2009, 14 h 34 min 53 s
Objet : Re: [Qt-interest] Why do Qt collection classes not offer signals and slots?

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


_______________________________________________
Qt-interest mailing list
Qt-interest at trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-interest



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20091218/2e9a3701/attachment.html