Iterator:

std::vector<CRoute*>::iterator itElem;
for(itElem= temp.m_paRoute.begin(); itElem!= temp.m_paRoute.end(); itElem++)
   m_paRoute.push_back(new CRoute((**itElem)));

Traversion:

for(int i=0; i< temp.m_paRoute.size(); i++)
   m_paRoute.pushback(new CRoute(temp.n_paRoute.at(i)));

was ist schneller /besser/ effizienter/ sicherer?

Grüße

Der Iterator ist natürlich sicherer, da du (wie leider viele andere) die Traversion potentiell Fehlerhaft geschrieben hast.

diese potenz kann er auch beim implementieren der iterator-version an den tag legen, oder meinst du was spezielles was ich uebersehe?

was ist fehlerhaft?

du benutzt einen Integer. std::size_t wäre hier angebracht oder zumindest ein anderer unsigned-Typ. Wenn du die Warnstufe bei deinem Compiler hochstellst sollte er dich sogar warnen. (Siehe dir den Rückgabetyp von std::vector<T>::size an).

meine erfahrungswerte mit gcc3.5, 4.01, icc 8.x, VS Studio Compiler ab 4.0):

BorisDieKlinge schrieb:

was ist schneller

Zugriff über den Indexer

BorisDieKlinge schrieb:

was ist besser

das hängt immer vom anwendungsfall ab:
- ist performance gefragt: indexer
- ist sicherheut gefragt: .at(i)

BorisDieKlinge schrieb:

was ist effizienter

Indexer

BorisDieKlinge schrieb:

sicherer

iterator oder .at(...)

BTW: besser ++it als it++ verwenden, dann spart man eine unnötige interne iterator kopie (liegt an der implementierung von post- und prefix-operatoren

BorisDieKlinge schrieb:

was ist schneller

Zugriff über den Indexer

[...]

BorisDieKlinge schrieb:

was ist effizienter

Indexer

äh? ist das eine Vermutung oder hast du auch eine Begrüdung für deine These?

äh? ist das eine Vermutung oder hast du auch eine Begrüdung für deine These?

7 Jahre strömungscode entwicklung, bei denen ausschließlich mit langen arrays hantiert wird. und ich rede jetzt von reiner zugriffszeit.
allein wenn man sich die ierator implementierung anschaut, so greift man beim indexer direkt auf die speicherstelle zu und beim iterator eben nicht.
jedenfalls konnte unser compiler (gcc3.x, icc unter linux und der vs 200x) bei der iterator version nie die performance des indexers erreichen.
und da unser chef generell etwas gegen OO bei berechnungskerneln hat... mussten wir eben ein paar performance tests machen

edit: wobei ich bei indexer den index-operator meine und nicht .at(i).
.at(i) und iteratoren hatten wir auch mal verglichen, aber da gab es glaub keinen nenenswerten unterschied und je nach compile rund optionen gab es da unterschiedliche ergebnisse.

Sicherlich hast du, was die gängigen Implementierungen angeh, Recht. Aber du kannst nicht einfach die Antwort so geben, als sei das irgendwo definiert. rüdigers Frage war sicherlich provokativ, aber sollte auch für das nächste Mal zu denken geben.

EDIT: Bjarne Stroustrup hatte z.B. für den C++2009-Standard vorgeschlagen, für alle Index-Ops der Container und Strings, eine Bereichsprüfung vorzuschreiben. Damit ist er meines Wissens nicht durch gekommen, zeigt aber, das deine Aussage ganz einfach nicht garantiert ist. Weil morgen könnte deine Aussage ganz einfach definitiv falsch sein. Und heute ist sie nicht garantiert.

sorry, wenn ich mich missverständlich ausgedrückt habe

meine erfahrungswerte mit gcc3.5, 4.01, icc 8.x, VS Studio Compiler ab 4.0):

Mit welchen Optimierungen? Ich kann mir eigentlich nicht vorstellen, dass es ein halbwegs guter Compiler nicht schafft, das Overhead eines Iterators für einen Vektor herauszuoptimieren. Im Zweifelsfall ist das doch einfach nur ein Zeiger auf die Elemente, d.h. er macht genau das, was Du beim Indexer anführst: direkter Zugriff auf eine Speicherzelle.

muffmolch schrieb:

meine erfahrungswerte mit gcc3.5, 4.01, icc 8.x, VS Studio Compiler ab 4.0):

Mit welchen Optimierungen? Ich kann mir eigentlich nicht vorstellen, dass es ein halbwegs guter Compiler nicht schafft, das Overhead eines Iterators für einen Vektor herauszuoptimieren. Im Zweifelsfall ist das doch einfach nur ein Zeiger auf die Elemente, d.h. er macht genau das, was Du beim Indexer anführst: direkter Zugriff auf eine Speicherzelle.

gcc
ADD_CXX_FLAGS("-O3 -march=athlon64 -fomit-frame-pointer -finline-functions -funroll-all-loops -fpermissive")

vs:
weitesgehend alle geschwindigkeitsoptimierungen waren aktiviert, wenn ich es richtig in erinnerung habe.

PS: was ich mir noch weniger vorstellen kann ist: wenn ein compiler die iteratoren weg compilieren kann, weiso sind fast alle neuen tollen compiler nicht in der lage mit dem schlüsselwort extern bei templates umzugehen???

PS: was ich mir noch weniger vorstellen kann ist: wenn ein compiler die iteratoren weg compilieren kann, weiso sind fast alle neuen tollen compiler nicht in der lage mit dem schlüsselwort extern bei templates umzugehen???

Na ja. Für 'extern' müssen sich die Compilerhersteller schon intensiv Gedanken um ein geeignetes Binärformat machen, in dem der Code vor dem Linken abgelegt werden kann. Das ist schon mit einigem Aufwand verbunden und solange es hier keine Standards geht und jeder sein eigenes Süppchen brüht, wäre das sowieso chaotisch, da nicht portabel.

Beim Iterator hingegen würde ich doch eigentlich vermuten, dass hier wirklich nur einige triviale Funktionen geinlined werden sollten. Dachte ich. Anscheinend irre ich mich ja.

EDIT: Bjarne Stroustrup hatte z.B. für den C++2009-Standard vorgeschlagen, für alle Index-Ops der Container und Strings, eine Bereichsprüfung vorzuschreiben.

das hat er bestimmt nur als scherz gemeint...

Optimierungen haben eine bessere Wertschöpfung für die Industrie, als ein Verstecken von Template-Code. Deswegen optimieren die Compiler alles so schlau.

Optimierungen haben eine bessere Wertschöpfung für die Industrie, als ein Verstecken von Template-Code. Deswegen optimieren die Compiler alles so schlau.

Ich glaube da geht es weniger um ein Verstecken als eher um ein Beschleunigen der Kompilation und das wäre ja durchaus (von ganz erheblichem!) Nutzen.

Index:
1. Index inkrementieren
2. Index zum Basiszeiger addieren
3. Resultierenden Zeiger dereferenzieren

Iterator:
a. Iterator inkrementieren
b. Iterator dereferenzieren

Ich denke, dass viele Prozessoren die Schritte 2 und 3 gleichzeitig ausführen können. Aber gilt dies für alle Indexgrößen?

Ist die Iteratorvariante immer noch langsamer, wenn man einen Zeiger als Iterator nimmt?

Artchi schrieb:

Optimierungen haben eine bessere Wertschöpfung für die Industrie, als ein Verstecken von Template-Code. Deswegen optimieren die Compiler alles so schlau.

Ich glaube da geht es weniger um ein Verstecken als eher um ein Beschleunigen der Kompilation und das wäre ja durchaus (von ganz erheblichem!) Nutzen.

Schnelleres Kompilieren geht heute mit Precompiled Headers. Wenn ich SmartWin++ benutze, dauert das Kompilieren ohne PCH sehr lange (habe leider keine Zeit gestoppt). Mit PCH wird das ganze um ein vielfaches gekürzt! Seit dem benutze ich immer PCHs. Sehe hier also keinen Grund auf export angewiesen zu sein, da PCHs heute (hoffentlich) zu den Features gängiger Compiler gehört.

Die Forderung nach export ist eher die Möglichkeit für das verstecken von Sourcecode. Für Closedsource-Libs eindeutig ein Argument gegen Templates.

Weiterhin: ist das Ergebnis beim Cameau auch wirklich mehr Kompile-Performance? Ich kann mich irren, aber laut Cameau-Erfahrungsbericht ist da nichts schneller. Der Bericht hat sich eher niederschmetternd gelsen. Alles eher noch kompilizierter. Ist aber schon seeehr lange her, als ich deren Dokument gelesen hatte.

PS: was ich mir noch weniger vorstellen kann ist: wenn ein compiler die iteratoren weg compilieren kann, weiso sind fast alle neuen tollen compiler nicht in der lage mit dem schlüsselwort extern bei templates umzugehen???

Wenn der Himmel wirklich blau ist, wieso schreibt man dann Koffer mit K und nicht mit G???

muffmolch schrieb:

PS: was ich mir noch weniger vorstellen kann ist: wenn ein compiler die iteratoren weg compilieren kann, weiso sind fast alle neuen tollen compiler nicht in der lage mit dem schlüsselwort extern bei templates umzugehen???

Wenn der Himmel wirklich blau ist, wieso schreibt man dann Koffer mit K und nicht mit G???

weil der himmel nicht für alle blau ist... je nach aufnehmbarem spektrum eben. zudem: schonmal nachts den himmel angeschaut? siehste...

wieso sollte der iterator überhaupt langsamer sein?
in meiner stl implementation ist der iterator eines vector<int> ein int*. Es lassen sich also keinerlei aussagen darüber treffen, ausser die, dass bei deiner implementation der iterator langsam ist.

index zugriff war so schnell wie index zugriff auf normales array
Iterator war so schnell wie pointer zugriff auf normales array, also schneller