performance of loops iterating over selectedItems() - qt

Question

I had an issue with setting items as selected... so I took a peek at the QGraphicsScene::selectedItems() function.
Ever since, I became really nervous about using it in loops.
In a construct like this:
foreach(QGraphicsItem* selectedItem, selectedItems())
{
// perform action with selectedItem
}
Will every iteration recalculate the selectedItems() function ?
(I think so, because the above becomes unstable if inside the loop I change selection)
I imagine this would have a big impact on my code speed...
So I am starting to change me code everywhere, to:
QList<QGraphicsItem*> sel = selectedItems();
foreach(QGraphicsItem* selectedItem, sel)
{
// perform action with selectedItem
}
Am I correct in assuming this will speed up the program ?
(or will it make it slower because of copying, while the replacement in loop test would not change, if I am wrong and the selectedItems() doesn't really get through all its code ?)
I wonder what other functions should be avoided... like perhaps sceneRect() or boundingRect() for items inheriting from QGraphicsItem.... Is it right to copy those to a QRectF if used more than once in the same function ?

Answer 1

foreach(QGraphicsItem* selectedItem, selectedItems())
{
// perform action with selectedItem
}
In this case, you're iterating over the returned selected items and as you've discovered, if the selection is changed, this can cause problems.
Is this better?
QList<QGraphicsItem*> sel = selectedItems();
foreach(QGraphicsItem* selectedItem, sel)
{
// perform action with selectedItem
}
The simple answer is yes.
will it make it slower because of copying
Not necessarily. If the container is unchanged, it won't make a difference.
However, Qt implements implicit sharing, which ensures that a container, such as QList will share the data in this case and only make a copy (COW - copy on write), when one of the copies changes.
I wouldn't worry too much over sceneRect and boundingRect, as they just return simple data types such as QRectF, rather than a container of items, so implicit sharing is not required here. Only in extreme circumstances would caching such returned values make a noticeable difference.