Imkrement Operator: Wann postfix und wann prefix verwenden?

[CStoll]

Beide Operatoren haben einen beabsichtigten Seiteneffekt - sie erhöhen die Variable, auf die sie angewendet werden (aus technischer Sicht ist der primäre Effekt die Wertrückgabe).

Und als Entscheidungsgrundlage: Wenn der Rückgabewert des Operators weiter ausgewertet werden soll, nimm die Variante, die das richtige Ergebnis liefert (++x liefert den erhöhten Wert, x++ den Originalwert). Wenn der Rückgabewert egal ist, nimm ++x, der ist potentiell schneller^*.

^* Bei Build-in Typen macht es in der Regel keinen Unterschied, aber selbstdefinierte Typen müssen sich idR kopieren, um die Semantik von op++ erfüllen zu können - und dieses Kopieren kann teuer sein (und nicht jeder Compiler ist in der Lage es zu optimieren).

[BorisDieKlinge]

sorry war falsch hier

[nman]

CStoll schrieb:

Und als Entscheidungsgrundlage: Wenn der Rückgabewert des Operators weiter ausgewertet werden soll, nimm die Variante, die das richtige Ergebnis liefert (++x liefert den erhöhten Wert, x++ den Originalwert). Wenn der Rückgabewert egal ist, nimm ++x, der ist potentiell schneller

Anders gesagt: Immer Präfix, außer Du brauchst Postfix.

[stutzig]

CStoll schrieb:

Wenn der Rückgabewert egal ist, nimm ++x, der ist potentiell schneller^*.

wieso könnte der schneller sein?

[rüdiger]

stutzig schrieb:

CStoll schrieb:

Wenn der Rückgabewert egal ist, nimm ++x, der ist potentiell schneller^*.

wieso könnte der schneller sein?

class A {
  A &operator++() { ... return *this; } //prefix
  A operator++(int) { // postfix
    A tmp(*this);
    ++*this;
    return tmp;
  }
};

Aber war es nicht so, dass der Compiler auch bei Builtin-Typen a++ zu ++a machen konnte?

[CStoll]

stutzig schrieb:

CStoll schrieb:

Wenn der Rückgabewert egal ist, nimm ++x, der ist potentiell schneller^*.

wieso könnte der schneller sein?

Vielleicht solltest du nicht mitten im Beitrag aufhören mit Lesen - das hochgestellte * kennzeichnet bei mir normalerweise Fußnoten, die weiter unten erläutert werden

@rüdiger: Bei Build-ins durchaus - bei selbstgebauten Typen eher nicht.

[hustbaer]

Bei selbstgebauten Typen ist es auch oft kein Problem alles wegzuoptimieren was post-inkrement langsamer machen könnte. Manchmal aber eben schon.

Das Problem ist dabei denke ich weniger der Compiler, als z.B. Funktionen deren Implementierung der Compiler nicht kennt, und die daher aufgerufen werden müssen (könnten ja erwünschte Seiteneffekte haben). z.B. das Locken von Mutexen, "interlocked" Funktionen oder dynamische Speicheranforderungen können im Normalfall nicht wegoptimiert werden.

Von daher die Regel: wenn post- oder pre- egal ist, dann pre-inkrement.

[stutzig]

ach so
ihr meint ganz speziell c++.
gilt es auch für andere programmiersprachen mit ++ operator?

[hustbaer]

Was "wir" meinen kann ich nicht sagen, *ich* habe die Frage so interpretiert - ist halt ein C++ Forum hier.

Was für andere Sprachen gilt kann ich nicht sagen.

[rüdiger]

Die Problematik existiert für alle Programmiersprachen, mit selbst definierbaren ++-Operatoren

[CStoll]

@hustbaer: Ja, wenn der Compiler den Code hat - und ausreichend Intelligenz besitzt.

@stutzig: Das Problem wird immer dann interessant, wenn es zwei verschiedene Inkrement-Funktionen gibt - die unabhängig voneinander implementiert werden könnten (C# und D definieren afaik eine Funktion für beide Varianten - da macht sich das Optimieren etwas einfacher).