Ja, danke für die Aufklärung :-)

Salute herbivore

Okay, das macht es klarer :-)


Gruss Peter

Ich weiß nicht, wie bei euch die Coderichtlinien aussehen, aber bei uns heißt eine klare Regel, dass der Übersichtlichkeit halber nicht zwei unterschiedliche Aktionen in eine Zeile verbaut werden dürfen (Ausnahme natürlich die Initialisierung von Zählvariablen in Schleifen).
Weder noch wären somit erlaubt, das Inkrementieren von i müsste vor oder nach dem Funktionsaufruf in einer extra Zeile stehen (idR danach).
Diese Regel finde ich auch ganz sinnvoll, weil man das Inkrementieren dann wirklich schwerer übersehen kann.
Ob i++ oder ++i, ist ziemlich egal, wenn es in einer Zeile als einzige Anweisung steht und sonst nichts weiter. Was man da verwendet, ist wirklich nur noch eine Frage des persönlichen Geschmacks.
Bei Schleifen hängt es meiner Meinung nach auch stark von der Situation ab.
Wenn ich eine Liste mit Hilfe einer FOR-Schleife durchlaufen will, dann schreibe ich hier künstlich ein ++i zu erzwingen, indem man mit i=-1 anfängt, das wäre doch unsinnig.
Wenn ich jetzt natürlich eine Schleife 10 mal durchlaufen will und die Zahlen 1 - 10 ausgeben, dann ist natürlich lesbarer, ich lasse die Schleife von 0 bis 10 laufen und inkrementiere mit ++i.

Allgemein:
Je nachdem woher das "i" überhaupt kommt, fände ich im Falle, dass ich es selbst zuvor erstellt hätte, auch befremdlich, wenn ich es mit 0 initialisiert hätte, wenn doch der erste Wert, den es bei der Verwendung haben soll, 1 ist.
Also quasi: fände ich seltsam und verwirrend, da ich, wenn ich die Initialisierung von i mit 0 sehe, davon ausgehe, dass dies der erste Wert für i ist, der verwendet wird. würde ich da eher schreiben!

gruß
sth_Weird

Zitat von sth_Weird

Wenn ich eine Liste mit Hilfe einer FOR-Schleife durchlaufen will, dann schreibe ich for (int i = 0; i < myList.Count(); i++) { } hier künstlich ein ++i zu erzwingen, indem man mit i=-1 anfängt, das wäre doch unsinnig

Nein, das ist ein Trugschluss, dass du bei -1 anfangen musst. Sowohl bei i++ als auch bei ++i musst du mit dem gleichen Wert anfangen.

Genau, die Anweisung nach dem zweiten Semikolon wird erst ausgeführt wenn der Anweisungsblock durch ist

for (int i = 0; i < myList.Count(); i++)
{
    TuWas(myList[i]);
}

ist äquivalent zu

int i = 0;
while (i < myList.Count())
{
    TuWas(myList[i]);
    i++;
}

Hallo sth_Weird!

FULLACK

Das ist das, was ich oben mit

Zitat

Und was das ursprüngliche Beispiel angeht: Hier geht es um zwei Aktionen: Auslesen eines Wertes, und dann den Index erhöhen. Wenn das doch zwei Aktionen sind, warum sollte ich die krampfhaft in eine Zeile zusammenziehen? Das trägt IMHO ebenfalls nicht zur Lesbarkeit bei.

meinte.

Viele Grüße,


Golo

Zitat

Nein, das ist ein Trugschluss, dass du bei -1 anfangen musst. Sowohl bei i++ als auch bei ++i musst du mit dem gleichen Wert anfangen.

Asche auf mein Haupt, da hab ich Mist erzählt (hat oben aber schon einer korrigiert).
Hab das Konstrukt mit dem ++i so noch nie verwendet.

Kurz und knackig: lesbar bitte. Erst index, dann increment.

Abgesehen davon, lesbar ist in managed Sprachen sowiso besser. Optimiert ja sowiso alles der Compiler:
baut auch schönes x86

inc i; //i++

inc i; //++i

mov eax, i;
mov temp, eax; //temp = i;
inc i; //++i
mov eax, temp;
mov post, eax; //post = temp;

inc i; //++i
mov eax, i;
mov pre, eax; //pre = i;

Drum: überlasst das optimieren dem Compiler, der kanns (meist) besser.
Früher war das in C/C++ noch ein Argument, dass man Prefix bevorzugen sollte, weil damit kein Temp erzeugt wird, aber auch das sollten die meisten Compiler können (bei STL-Iteratoren bin ich mir allerdings nicht sicher).

Hallo BhaaL,

um Optimierung ging es doch gar nicht. Es ging doch von Anfang an um Lesbarkeit und dann noch um Sinnhaftigkeit. Wenn wir über eine separate Anweisung reden, sind ++i und i++ im Ergebnis semantisch gleichbedeutend. Das sieht man ja auch schön an deinem "x86"-Code. Dann muss aber die Frage erlaubt sein, welche von den beiden semantisch gleichbedeutenden Varianten man verwenden sollte. Warum ich finde, dass man, wenn man die Wahl hat, ++i verwenden sollte, habe ich ja nun ausführlich begründet. Auch warum ich sie lesbarer finde.

herbivore

Hallo zusammen

@herbivore
Als Nebenbemerkung finde ich die Sache mit Priorität auf Lesbarkeit, auch weil der Code sowieso optimiert wird, passend und sinnvoll.

Ich denke somit ist alles gesagt, mehrfach :-)


Gruss Peter

Zitat von herbivore

um Optimierung ging es doch gar nicht.

Gut, mein Fehler, kam mir aber ein wenig komisch vor, dass alle nur um die "Schönheit" und Lesbarkeit (aus mehreren Sichten) der Operation geschrieben haben. Unterschwellig hatte ich da irgendwie die ein oder andere Diskussion (auf Basis C/C++) im Kopf, wo die eisernen Verfechter der Prefix-Variante immer mit Performance, kein temp usw. argumentiert haben. Und wer die beiden Sprachen kennt, dem muss ich vermutlich nix über Lesbarkeit erzählen.

Zitat von herbivore

Dann muss aber die Frage erlaubt sein, welche von den beiden semantisch gleichbedeutenden Varianten man verwenden sollte. Warum ich finde, dass man, wenn man die Wahl hat, ++i verwenden sollte, habe ich ja nun ausführlich begründet. Auch warum ich sie lesbarer finde.

Geschmäcker sind zum Glück verschieden, und was das angeht ist mir die Postfix Variante lieber/gebräuchlicher - weils jeder so verwendet, weil C++ auch C++ heißt, weils eh alle trotzdem lesen können, oder warum auch immer.
Abgesehen davon gehts mir aber ähnlich wie dir - wenn keine bestimmte Intention dahinter ist (wie im Beispiel gezeigt someArray[++idx] oder MyMethod(++i)), ist mir egal ob dort Prefix oder Postfix steht - und sowas mach ich in Produktivcode meist sowiso nicht, maximal in einem Quick&Dirty Prototyp.

Wenn man dann aber so weit geht, und das ganze mit Methodenaufrufen vergleicht, müsste man bei der Prefix-Variante auf ++(i) (eigentlich: ++(ref i)) umsteigen, weil ++ (und auch --) den Wert der Variable selbst ändern. Wenn ich mir da andere unäre Operatoren ansehe (beispielsweise ~ oder auch -) ist das nicht der Fall. Drum gefällt mir der Vergleich da auch irgendwie nicht; auch wenns im Hintergrund sowiso zu nem i = operator++(i) werden würde.
Von der Seite betrachtet machts auch Sinn, warum ++i eigentlich i+1 liefert, i++ aber i.