qt foreach
-
aber bei
foreach(int &s, a)
sollte doch s eine referenz auf das aktuelle objekt von a sein, welches ich auch wieder beschreiben sollen könnte?
kann ich foreach mit zeigern kombinieren oder muss ich hier mit for arbeiten?
-
Dieser Thread wurde von Moderator/in evilissimo aus dem Forum C++ in das Forum Andere GUIs - Qt, GTK+, wxWidgets verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Ich würde auf die Verwendung von foreach eher vollkommen verzichten.
foreach ist ein Makro:
1. sind Makros böse und 2. ist der Code der hinter dem Makro steckt ziemlich undurchsichtig.
Ich glaube zwar schon dass die Mädels und Jungs die hinter dem Code stecken sich einige Gedanken drüber gemacht haben aber warum einen einfachen Einzeiler durch einen Code ersetzen den man nicht versteht?
-
Wenn man sich die Details des foreach-Makros ansieht, so erfährt man das ein QListIterator genutzt wird. Dieser gibt jedoch nur const-Referenzen zurück, daher wird ein Ändern über diesen nicht möglich.
Daher selbst eine kleine for mit Iterator schreiben. Ist nicht wirklcih viel mehr code.
-
for (QList<int>::iterator s = a.begin(); s != a.end(); ++s)
danke für die hilfe
-
for (QList<int>::iterator s = a.begin(); s != a.end(); ++s)besser
for (QList<int>::iterator s = a.begin(), end = a.end(); s != end; ++s)dann sparst du dir den Funktionsaufruf pro Schleifendurchlauf.
-
Unnötige Mikrooptimierung.
-
Janjan schrieb:
Unnötige Mikrooptimierung.
Es ist prinzipiell keine unnötige Mikrooptimierung, wenn man sich Werte, die man öfters unverändert braucht, zwischenspeichert.
Ein QList::end() kann übrigens ziemlich teuer werden, schau dir den Code an.
-
l'abra d'or schrieb:
Janjan schrieb:
Unnötige Mikrooptimierung.
Es ist prinzipiell keine unnötige Mikrooptimierung, wenn man sich Werte, die man öfters unverändert braucht, zwischenspeichert.
Ein QList::end() kann übrigens ziemlich teuer werden, schau dir den Code an.Prinzipiell magst du schon recht haben, der Profiler von VS2008 sagt aber dass es keinerlei Unterschied macht.
Ich denke die meisten Compiler sind durchaus intelligent genug zu erkennen dass die Liste in der Schleife nicht verändert wird und das end() selbst auszulagern.
-
rean schrieb:
Ich denke die meisten Compiler sind durchaus intelligent genug zu erkennen dass die Liste in der Schleife nicht verändert wird und das end() selbst auszulagern.
Und genau das ist der Fall. Das Optimieren sollte man dem Compiler überlassen - er macht es sowieso besser.
-
Janjan schrieb:
Also wechsel einfach auf eine Lösung mittels Iteratoren.
nein, lieber einfach foreach durch BOOST_FOREACH austauschen. Dann gehen auch Referenzen. Und noch mehr (bis aufs verändern der Sequenz)
-
Wozu boost, wenn er Qt benutzt?
-
zum Beispiel um ein besseres foreach zu bekommen
-
"Besser" ist wohl Geschmackssache. Ich halte generell von solchen Makros nichts.
-
nee, mit Geschmack hat das nichts zu tun.
Mit boost geht:
int v[] = {1,2,3}; foreach (int x, v) ... foreach (int& x, v) ... foreach (const int& x, v) ...Mit QT glaube ich keins von denen. Also ist die Boost-Variante klar besser.
-
Janjan schrieb:
"Besser" ist wohl Geschmackssache. Ich halte generell von solchen Makros nichts.
Ich halte generell nicht von allgemeine Verteufelungen
Abgesehen sind Guards auch Makros *hust**hust*
-
Zeus schrieb:
Janjan schrieb:
"Besser" ist wohl Geschmackssache. Ich halte generell von solchen Makros nichts.
Abgesehen sind Guards auch Makros *hust**hust*
*hust**hust* Guards sind auch kein solches Makro wie hier beschrieben. Lesen ist hilfreich. *hust**hust*
DrGreenthumb schrieb:
nee, mit Geschmack hat das nichts zu tun.
Mit boost geht:
int v[] = {1,2,3}; foreach (int x, v) ... foreach (int& x, v) ... foreach (const int& x, v) ...Mit QT glaube ich keins von denen. Also ist die Boost-Variante klar besser.
Und du weißt jetzt aus dem FF was die Voraussetzungen für dieses Makro sind? Worauf greift es zu?
-
die liste muss ein array oder ein container mit begin()/end() und den üblichen typedefs sein. Ansonsten beschwert sich schon der compiler.