for (int n = 0; n < foo(); ++n)

dieses hier

int foo_bla = foo();
for (int n = 0; n < foo_bla; ++n)

?

for (auto i = foo(); i-- != 0; )

Wenn er sieht, dass foo() immer das Gleiche zurückgibt, sehr wahrscheinlich, ja. Bitte aber auch bedenken, dass das hier wesentlich schneller ist, falls die Reihenfolge nicht wichtig ist:

for (auto i = foo(); i-- != 0; )

das ist nice, muss ich mir merken!(sorry für den doppelpost)

cooky451 schrieb:

Wenn er sieht, dass foo() immer das Gleiche zurückgibt, sehr wahrscheinlich, ja. Bitte aber auch bedenken, dass das hier wesentlich schneller ist, falls die Reihenfolge nicht wichtig ist:

for (auto i = foo(); i-- != 0; )

das ist nice, muss ich mir merken!(sorry für den doppelpost)

Merk dir es, aber verwende es sogut wie nie. Man sollte immer gut lesbaren Code vorziehen. Außerdem ist es ganz sicher nicht wesentlich schneller. Zu 90% ist die Schleife für Performance sowieso unwichtig.
http://en.wikipedia.org/wiki/Program_optimization#Bottlenecks

In computer science, the Pareto principle can be applied to resource optimization by observing that 80% of the resources are typically used by 20% of the operations. In software engineering, it is often a better approximation that 90% of the execution time of a computer program is spent executing 10% of the code (known as the 90/10 law in this context).

//edit es ist nichtmal klar, ob der Compiler checkt was du machen willst. Im worst case ist er verwirrt und schaltet dir erstmal SSE aus.

Also ich würde mich auch genötigt fühlen, dieses Konstrukt länger zu durchdenken und danach einen Kommentar drüber zu schreiben und _danach_ die Schleife durch die lesbar Variante zu ersetzen.

Aua.

otze schrieb:

//edit es ist nichtmal klar, ob der Compiler checkt was du machen willst. Im worst case ist er verwirrt und schaltet dir erstmal SSE aus.

Bitte was? Natürlich rafft der das.

An so ein Konstrukt gehört ein Kommentar. Mit Begründung(also Benchmark).

Und zu dem Zweiten Teil: das hast du natürlich getestet? Ich habe da nicht mehr so viel Vertrauen in meine Compiler.

Warum Aua? Dieses Konstrukt ist so unnnatürlich,

What? Ich benutze das in etwa 10 mal öfter als das "normale" Konstrukt, und offen gesagt finde ich es wesentlich leichter zu lesen. Ich bevorzuge es auch, wenn Performance garkeine Rolle spielt.

otze schrieb:

dass ich erstmal analysiere, ob es überhaupt einen Sinn hat, rückwärts zu iterieren. Das kostet mich im Zweifelsfall, je nach Codekenntnis, 10-30 Minuten, bevor ich daran weiter arbeiten kann.

Wie lang sind denn deine Schleifen, dass man da 10 Minuten dran lesen kann?

otze schrieb:

Das ist genauso, wie bei Leuten, die ihre Laufvariablen vor dem Loop deklarieren wo ich den ganzen Folgecode durchsuche, ob der Wert der Variablen noch irgendwo benutzt wird.

Wenn das ernsthaft ein relevanter Zeitfaktor ist kann man den Code eh gleich in die Tonne kloppen, weil der Gültigkeitsbereich offensichtlich zu groß ist.

otze schrieb:

An so ein Konstrukt gehört ein Kommentar. Mit Begründung(also Benchmark).

Ich denke sowas ist Allgemeinwissen, ich schreib' ja auch nicht bei jedem std::transform daneben dass die Reihenfolge nicht garantiert ist.

otze schrieb:

Und zu dem Zweiten Teil: das hast du natürlich getestet? Ich habe da nicht mehr so viel Vertrauen in meine Compiler.

Klar habe ich das getestet.

otze schrieb:

Warum Aua? Dieses Konstrukt ist so unnnatürlich,

What? Ich benutze das in etwa 10 mal öfter als das "normale" Konstrukt, und offen gesagt finde ich es wesentlich leichter zu lesen. Ich bevorzuge es auch, wenn Performance garkeine Rolle spielt.

Das ist relativ untypisch. Was sagen deine Kollegen dazu, für wie lesbar halten sie den Code? Wenn man nicht gerade für sich selbst entwickelt ist Lesbarkeit das oberste Gebot - und da spielen Konventionen eine wichtige Rolle, denen dein Konstrukt nicht so recht entspricht.

otze schrieb:

dass ich erstmal analysiere, ob es überhaupt einen Sinn hat, rückwärts zu iterieren. Das kostet mich im Zweifelsfall, je nach Codekenntnis, 10-30 Minuten, bevor ich daran weiter arbeiten kann.

Wie lang sind denn deine Schleifen, dass man da 10 Minuten dran lesen kann?

Man weiß beim unkommentieren Code nicht, ob dieses Konstrukt eine (i.d.R. nutzlose) Performanceoptimierung ist, oder ob die Iteration rückwärts einen semantischen Zweck erfüllt.

Das ist relativ untypisch. Was sagen deine Kollegen dazu, für wie lesbar halten sie den Code? Wenn man nicht gerade für sich selbst entwickelt ist Lesbarkeit das oberste Gebot - und da spielen Konventionen eine wichtige Rolle, denen dein Konstrukt nicht so recht entspricht.

Nicht, dass ich Arbeitskollegen hätte als fast Student, aber die Leute, die ich kenne, hätten damit keine Probleme. Ich verstehe offen gesagt auch nicht so ganz, was daran schwer zu lesen sein soll. Es ist eine Zeile Code, auch wenn ich die noch nie gesehen habe, kann ich in etwa so schnell erfassen was die macht wie ich lesen kann?

qwertfdassffds schrieb:

Man weiß beim unkommentieren Code nicht, ob dieses Konstrukt eine (i.d.R. nutzlose) Performanceoptimierung ist, oder ob die Iteration rückwärts einen semantischen Zweck erfüllt.

Das ist kein Argument dafür per "default" die langsamere Variante zu wählen. Ich weiß bei unkommentiertem Code nicht, ob das vorwärts Iterieren einen semantischen Zweck erfüllt, oder ob man das optimieren kann. Deshalb schreibe ich überall da, wo es einen Zweck erfüllt, ein Kommentar, und überall wo es egal ist, eben halt keinen. Würde anders ja auch wenig Sinn machen.

Es ist eine Zeile Code, auch wenn ich die noch nie gesehen habe, kann ich in etwa so schnell erfassen was die macht wie ich lesen kann?

Nein, eben nicht. Stell dir vor, du bist im Straßenverkehr. Du siehst ein quadratisches, türkisfarbenes Schild an einer Kreuzung, auf dem fett STOP steht. Du weißt, nachdem du es dir angeschaut hast und den Text gelesen hast, was gemeint ist. Wunderst dich aber, warum es nicht das übliche, rote Stop-Schild ist, bei dem du nichtmal mehr richtig liest, sondern in einem Sekundenbruchteil erfasst, welches Schild du vor dir hast (selbst, wenn es auf arabisch ist).

Das gleiche passiert beim Lesen des Quelltextes. Über das typische for(int i = 0; bla bla...) huscht jeder kurz drüber, ohne die Konzentration auf die wesentlichen Aspekte des Quelltextes zu ignorieren. Bei deinem Rückwärtskonstrukt muss man erstmal anhalten und genau nachlesen, was gemeint ist. Natürlich geht das ziemlich fix, trotzdem stört es den Lesefluss, vor Allem wenn man sich fragt, wo der Haken ist, und warum du nicht die übliche Version genommen hast. Man analysiert das Ganze nochmal und stellt fest, dass es keinen unterschied gibt, trotzdem ist es ein Stolperstein. Man verliert das Wesentliche aus dem Fokus, völlig unnötigerweise. Code, der mit solchen unüblichen Konstrukten durchsetzt ist, liest sich genauso holperig wie ein text, der in einem ungewöhnlichen, unflüssigen Text geschrieben wurde. Man kanns lesen, es ist aber sicher keine Freude.

Auch wenn Du den Code ohne Performance-Gewinn vorziehen würdest: die meisten schreiben es nicht so, daher ist es erstmal unüblich und somit verwirrender. Und Verwirrung steht guter Lesbarkeit quasi gegenüber.

Edit: Bis hier hat das pumuckl viel cooler erklärt.

Und dann würde mich Dein Benchmark-Programm interessieren, das zeigt, dass die Variante performanter ist. Hast Du die zufällig gerade zur Hand?

@Eisflamme
Ja, er wäre beim ersten mal verwirrt. Vielleicht beim zweiten mal. Danach ist es aber egal. Ich bin andererseits offen gesagt eher geschockt, dass das nicht alle so machen. Ich muss immer schon schmunzeln wenn ich die andere Variante sehe wo es doch offensichtlich ist, dass es auch rückwärts ginge.

Ich hab' mal nen relativ aufwendigen Benchmark geschrieben mit Matrizen etc., den finde ich allerdings gerade nicht. Aber ich hab hier mal kurz was zusammengefrickelt. (Hoffentlich ohne Fehler.)

#include <chrono>
#include <vector>
#include <iostream>

template <typename Clock = std::chrono::steady_clock>
class stopwatch
{
	typename Clock::time_point last_;

public:
	stopwatch()
		: last_(Clock::now())
	{}

	void reset()
	{
		*this = stopwatch();
	}

	typename Clock::duration elapsed() const
	{
		return Clock::now() - last_;
	}

	typename Clock::duration tick()
	{
		auto now = Clock::now();
		auto elapsed = now - last_;
		last_ = now;
		return elapsed;
	}
};

template <typename T, typename Rep, typename Period>
T duration_cast(const std::chrono::duration<Rep, Period>& duration)
{
	return duration.count() * static_cast<T>(Period::num) / static_cast<T>(Period::den);
}

void foo(std::vector<char>& v)
{
	stopwatch<> timer;
	for (int i = v.size(); i-- != 0; )
		v[i] = 77;
	std::cout << "Foo time: " << duration_cast<float>(timer.elapsed()) << '\n';
}

void bar(std::vector<char>& v)
{
	stopwatch<> timer;
	for (int i = 0; i != v.size(); ++i)
		v[i] = 44;
	std::cout << "Bar time: " << duration_cast<float>(timer.elapsed()) << '\n';
}

int main()
{
	std::size_t n;
	std::cin >> n;
	std::vector<char> v(n * 1024 * 1024);
	foo(v);
	bar(v);
}

Am besten ein paar mal hintereinander laufen lassen, damit der RAM vorbereitet ist. n zwischen 512 und 1024 sollte gute Ergebnisse bringen.

for (auto i = foo(); i-- != 0; )

Wenn foo einen vorzeichenlosen Typen zurückgibt, hast du eine Endlosschleife. So viel zum Thema "gut lesbar".

Edit: Gilt natürlich nur, wenn du deinen Code erst mal auf das anpasst, was der OP geschrieben hat, nämlich eine Iteration von 0 bis foo() -1 und nicht wie bei dir eine Iteration von 1 bis foo(). Also gleich zwei Fehler in "so einem einfachen Code".

cooky451 schrieb:

for (auto i = foo(); i-- != 0; )

Wenn foo einen vorzeichenlosen Typen zurückgibt, hast du eine Endlosschleife. So viel zum Thema "gut lesbar".

Falsch. Wird der zweite Satz dadurch richtiger?

cooky451 schrieb:

for (auto i = foo(); i-- != 0; )

Wenn foo einen vorzeichenlosen Typen zurückgibt, hast du eine Endlosschleife. So viel zum Thema "gut lesbar".

Dein Kommentar zeigt wirklich Mängel in der Lesbarkeit auf, aber anders als Du denkst...

Falsch. Wird der zweite Satz dadurch richtiger?

Siehe Edit:

Edit: Gilt natürlich nur, wenn du deinen Code erst mal auf das anpasst, was der OP geschrieben hat, nämlich eine Iteration von 0 bis foo() -1 und nicht wie bei dir eine Iteration von 1 bis foo(). Also gleich zwei Fehler in "so einem einfachen Code".

Edit: Gilt natürlich nur, wenn du deinen Code erst mal auf das anpasst, was der OP geschrieben hat, nämlich eine Iteration von 0 bis foo() -1 und nicht wie bei dir eine Iteration von 1 bis foo(). Also gleich zwei Fehler in "so einem einfachen Code".

Langsam wird's lustig. Aber dafür verstehe ich etwas mehr was pumuckl meint.

[..] Wie lang sind denn deine Schleifen, dass man da 10 Minuten dran lesen kann?
[...] Wenn das ernsthaft ein relevanter Zeitfaktor ist kann man den Code eh gleich in die Tonne kloppen, weil der Gültigkeitsbereich offensichtlich zu groß ist.

Ich arbeite hier mit zum Teil 15 Jahre alten open source code der von Wissenschaftlern und Studenten geschrieben wurde. Was meinst du, ist die durchschnittliche Codequalität? Natürlich wandert der Code in die Tonne, den neu zu schreiben ist gerade mein Job. Aber dafür muss ich erstmal verstehen was er macht. Und ich habe das Gefühl, dass es so kleine Abweichungen von der Konvention sind, die am meisten Zeit fressen.

Es gibt ja noch eine andere Konvention, die in einer zeitrelevanten Schleife eingesetzt werden kann:

std::size_t end = funct();
for(std::size_t i = 0; i != end; ++i){...}

kostet mich im durchschnitt 2 Sekunden zu verstehen. wenn ich nun das mit deiner Variante vergleiche stellt sich natürlich wiederholt die Frage, ob da nicht doch noch irgendwas passiert, immerhin hättest du die Schlife auch wie oben schreiben können.

//edit meine Tastatur liegt im persönlichen Krieg mit dem "e"

Langsam wird's lustig. Aber dafür verstehe ich etwas mehr was pumuckl meint.

Was ist so lustig? Ein typischer realer Ersatz von foo wäre vector::size(). Was passiert hier?

#include <vector>
#include <iostream>
using namespace std;

int main()
{
        vector<int> foo(2, 0);
        for(auto i = foo.size(); i >= 0; --i)
        {
                cout << i << endl;
                if(i > 1000) break;
        }
}

Ausgabe:

2
1
0
4294967295

Was ist so lustig? Ein typischer realer Ersatz von foo wäre vector::size(). Was passiert hier?

Wenn du noch ein bisschen überlegst und dir den Code anguckst den ich gepostet habe, wirst du verstehen warum das lustig ist.
Tipp: Die von dir geschriebene Schleife ist zu meiner grundverschieden.

@otze
Also ich weis nicht. Mir sind die ganzen Varianten alle gleich geläufig, und offen gesagt ist mir völlig egal was davon man benutzt, ich kann das alles gleich gut lesen. Und per default die langsamere Variante zu benutzen leuchtet mir einfach nicht ein.

Und selbst wenn man völlig verwirrt ist und aus dem Konzept kommt verliert man so höchstens 3 mal eine Minute, das ist es definitiv wert.

Ist es das? Zwei parallele Konventionen, für Schleifen, die nur dann semantisch gleichwertig sind, wenn die Reihenfolge keine Rolle spielt. Und als Ergebnis kriegen wir eine schnellere Ausführung des Schleifenkopfes (wie viel schneller eigentlich?), dessen Performanceimpakt vielleicht in einem von hundert Fällen wirklich was ausmacht (wenn überhaupt). Richtig auszahlen wird sich sowas vermutlich nur, wenn man Schleifen über riesige Bereiche hat (Numerik, Bildverarbeitung, ...?), deren Schleifenrümpfe nur sehr wenig Zeit benötigen (sonst fällt der Schleifenkopf prozentual nicht ins Gewicht und man sollte eher an der Anzahl der Iterationen schrauben). Vielleicht abgesehen von besagten speziellen Bereichen, wo solche Schleifen häufig vorkomemn, sehe ich da keinerlei Gewinn. Oder anders gesagt: Dem Ottonormalentwickler kommt nur höchst selten ein Fall unter, wo das Konstrukt eine messbare Optimierung darstellt. Das als allgemeinen Standard zu propagieren, der keines Kommentars bedarf, ist absurd. Wenn du in einem Projekt arbeitest, in dem ein großer Teil der Schleifen davon profitieren, dann machs im Projekt zum Standard. Ich bin zufälligerweise mit der Performanceoptimierung in einem Projekt vertraut, in dem viele Schleifen vorkommen, bei denen Reihenfolge keine Rolle spielt (aktuarieller Rechenkern für Lebensversicherungssoftware). Auch solche Schleifenoptimierungen sind dort schon erwägt worden, weil Performance hier wirklich eine Rolle spielt. Es bringt nur kein Ergebnis, das die Aufwände für eine entsprechende Umstellung rechtfertigen würde.

Am besten ein paar mal hintereinander laufen lassen, damit der RAM vorbereitet ist. n zwischen 512 und 1024 sollte gute Ergebnisse bringen.

.. und wie sind die Ergebnisse?

Mein Benschmark liefert folgendes:

klassisch
5000000 0s
dekrementierend
5000000 0.0179735s
abgefahren
5000000 0.0135209s

interessanterweise ist selbst die Variante mit counting_iterator (s.u.) und Algorithmus geringfügig schneller als die dekrementierende Variante

und hier ist der Code dazu

int foo() { return 1000*(2000 + 8000); }

int main()
{
    using namespace std;
    Watch uhr;
    {
        cout << "klassisch" << endl;
        Watch::Stopper stopper( uhr );
        int counter = 0;
        int bla = foo();
        for( int i=0; i<bla; ++i )
            counter += i % 2? +i: -i;
        cout << counter << " " << uhr << endl;
    }
    {
        cout << "dekrementierend" << endl;
        Watch::Stopper stopper( uhr );
        int counter = 0;
        for( int i=foo(); i-- != 0; )
            counter += i % 2? +i: -i;
        cout << counter << " " << uhr << endl;
    }
    {
        cout << "abgefahren" << endl;
        Watch::Stopper stopper( uhr );
        int counter = 0;
        for_each( boost::counting_iterator< int >(0), boost::counting_iterator< int >(foo()), [&counter]( int i ) { counter += i % 2? +i: -i; } );
        cout << counter << " " << uhr << endl;
    }
}