warum ++i performanter als i++
-
Ethon schrieb:
Ist imho das Gleiche wie bei den unterschiedlichen Inkrementierungsoperatoren.
Nein, weil bei deinem Beispiel keine Seiteneffekte auftreten.
kann die Erhöhung bereits beim Compilieren direkt berücksichtigt werden
Nun, ich bin mir unsicher, ob der Compiler beispielsweise array einfach mit einem anderen Wert initialisiert. Und eine Zeile Code ist auch ein schlechtes Beispiel.
Adressierungsmodi mit festem Displacement
Meinst du, dass einfach eine Konstante in den Befehl mitkodiert wird? Kann mir gerade nicht so viel drunter vorstellen.
-
knivil schrieb:
Adressierungsmodi mit festem Displacement
Meinst du, dass einfach eine Konstante in den Befehl mitkodiert wird? Kann mir gerade nicht so viel drunter vorstellen.
Genau das.
-
Man kann sich raussuchen, was man da generell macht, wenn es nicht drauf ankommt; das sollte nur konsistent gemacht werden und nicht mal so, mal so. Ich hab mir preincrement für alle Standard-Fälle angewöhnt. Andere nehmen postincrement.
Herb Sutter
schreibt (als Richtlinie, nicht als Pflicht):Guideline
Prefer preincrement. Only use postincrement if you're going to use the original value.Und weiter unten:
... Is the compiler allowed to notice this and simply rewrite the postincrement as preincrement as an optimization?
The answer is: No, not in general. The only time the compiler is allowed to optimize away unnecessary postincrement by rewriting it as preincrement is for builtin and standard types, such as
intandcomplex, whose semantics the compiler is allowed to know because they're standard.For class types, on the other hand, the compiler can't know the actual semantics of postincrement and preincrement--indeed, the two actually might not do the same thing. It would be a terrible thing indeed if the two functions didn't have the same semantics, and any programmer who wrote them with different semantics should be sacked on the spot. But, in general, that doesn't help the compiler, because it can't assume that the programmer is consistent.