Wieso schreiben C++ Progger for(int i=0; i!=99... anstatt i<99

[groovemaster]

Das ist nicht das Thema. Natürlich gibt es wichtigere Dinge. Aber genau für solche Sachen sollte man sich mal 5 Minuten Zeit nehmen. Später werden daraus sowieso Automatismen und tragen zum Unterschied zwischen guten Programmierern und "Hobby Proggern" bei.

[Nexus]

Fencer schrieb:

mal erlich leute,
wie wichtig ist das für die "meisten"(betont) Programme wirklich
Na gut ein Augenzwinkern mehr zeit gehabt.
Es gibt weiß Gott andere Dinge zu verbessern

Diese Sichtweise könnte man in nahezu jedem Thread vertreten. Es gibt immer etwas Wichtigeres, trotzdem sollte man auch Dinge wie dieses beachten. Aber du brauchst ja nicht mitzudiskutieren, wenn es deiner Meinung nach unwichtig erscheint.

Abgesehen davon hat < den Vorteil, dass bei Manipulationen der Zählvariable innerhalb der Schleife trotzdem eine korrekte Abbruchbedingung bleibt (wie bereits gesagt wurde).

[Nanyuki]

Nexus schrieb:

Abgesehen davon hat < den Vorteil, dass bei Manipulationen der Zählvariable innerhalb der Schleife trotzdem eine korrekte Abbruchbedingung bleibt (wie bereits gesagt wurde).

...und vor allem auch korrekt funktioniert, falls die Bedingung schon am Anfang nicht erfüllt ist.

[otze]

Nexus schrieb:

Diese Sichtweise könnte man in nahezu jedem Thread vertreten. Es gibt immer etwas Wichtigeres, trotzdem sollte man auch Dinge wie dieses beachten. Aber du brauchst ja nicht mitzudiskutieren, wenn es deiner Meinung nach unwichtig erscheint.

Wenn es immer etwas wichtigeres gibt, hat es keinen Sinn dies hier zu beachten, weil es n Dinge gibt, die eine höhere priorität haben. Dazu gehören Code Lesbarkeit, Code Konventionen usw. Du musst auch anderen deswegen nicht den Mund verbieten(oder es anderen nahe legen nicht mitzudiskutieren) weil es ein absolut berechtigter Einwand ist.

In C++ vertraust du dem Compiler in allen microoptimierungen. Das hat durchaus Sinn, denn oftmals kennst du den Kontext des Codes/der funktion/der Klasse nicht, und C++ Codeoptimierungen sind sehr oft kontextabhängig(templates und konsorten). Also sagen wirs kurz und knapp: Oft weis der Compiler einfach mehr als du. Was er draus macht ist eine andere Geschichte, aber wenn der Compiler deinen Optimierten Code nachträglich wieder ganz anders umsetzt, war alles Umsonst

Hinzu kommt, dass diese mikrooptimierungen Entwicklungszeit kosten, und der Effekt ist oftmals nichtmal messbar. Ein Programm verbringt durchschnittlich 95% seiner Ausführungszeit in 10% des Codes. Wenn also etwas optimiert werden muss, dann diese 10%, welche Teile das genau sind, weist du allerdings erst nach einem profiler durchlauf. Und wer sagt, dass so ein durchlauf überhaupt stattfindet? Wenn das Programm schnell genug ist, und alle Anforderungen erfüllt, dann will ich code wartbarkeit nicht gegen geschwindigkeit tauschen.

Mein Prof in Datenstrukturen sagt eigentlich jede Vorlesung: "sie können optimieren wie sie wollen, aber haben sie auch nur einen unnötigen Festplattenzugriff, war alles umsonst".

Abgesehen davon hat < den Vorteil, dass bei Manipulationen der Zählvariable innerhalb der Schleife trotzdem eine korrekte Abbruchbedingung bleibt (wie bereits gesagt wurde).

Das ist korrekt. Aber warum sollte ich in dieser Situation überhaupt eine normale zählschleife wählen? Wenn ich eh schon in der indexreinhenfolge rumspiele ist es nur eine zusätzliche Fehlerquelle, wenn die Schleife am Ende nochmals von selbst Inkrementiert.

Das tolle daran gleich was anderes zu nehmen ist auch, dass jeder weis, dass in der Schleife irgendwas *komplizierteres* als ne simple inkrementierung stattfindet, ein for-Schleifenkopf erweckt nunmal den Eindruck, dass man nur stupide irgendwas wiederholen will. Noch ein schicker kommentar vor das while konstrukt, und dein Code ist gleich viel schöner und lesbarer.

@Nanyuki

...und vor allem auch korrekt funktioniert, falls die Bedingung schon am Anfang nicht erfüllt ist.

Das wäre dann aber ein wirklich netter Seiteneffekt, der seine eigenen Kommentarzeilen braucht. Und wenn ich eh schon kommentare setzen muss, spricht nichts dagegen dann statt != ein < zu verwenden.

[Christoph]

Es gibt Systeme, auf denen < vs. != tatsächlich zu einem messbaren und signifikanten Unterschied führt. Ein Szenario ist z.B. ein 8-Bit-Mikrocontroller und eine Zählschleife mit einem 16-Bit-Counter. Weil man hier mehr als eine Maschinenanweisung für den Vergleich braucht, kann ein Test auf "ungleich" kürzeren Code erzeugen als einer auf "kleiner als". Vorausgesetzt natürlich der Compiler erkennt diese Optimierung nicht selbst und vorausgesetzt die Maschinenbefehle des Mikrocontrollers erfordern diese Differenz.

[Nexus]

otze schrieb:

Wenn es immer etwas wichtigeres gibt, hat es keinen Sinn dies hier zu beachten, weil es n Dinge gibt, die eine höhere priorität haben. Dazu gehören Code Lesbarkeit, Code Konventionen usw.

Es gibt immer n Dinge, die eine höhere Priorität haben. Ich glaube kaum, dass jemand so perfekt programmiert, dass er nur noch solche Luxusprobleme beachten muss. Und selbst wenn der Compiler einem die Möglichkeit nimmt, selbser eine Änderung zu bewirken, heisst das noch lange nicht, dass es nicht angebracht ist, die Sache zumindest in der Theorie genauer anzuschauen.
Ich bleibe bei meiner Meinung: Diese Ansicht kann man nahezu überall bringen; die Tatsache, dass es wichtigere Dinge gibt, ist kein Argument.

otze schrieb:

Du musst auch anderen deswegen nicht den Mund verbieten(oder es anderen nahe legen nicht mitzudiskutieren) weil es ein absolut berechtigter Einwand ist.

Ich wollte ihm nicht sagen, er dürfe hier nicht mitdiskutieren. Aber es ist doch so, dass wenn ihn diese Kleinigkeit nicht interessiert, ist es ja ihm überlassen, ob er mitredet oder nicht. Was deine Unterstellung betrifft: Ich finde es übrigens genau so daneben, sich gegen eine Diskussion über ein Thema zu stellen mit dem Grund, es gäbe Wichtigeres.

otze schrieb:

Das ist korrekt. Aber warum sollte ich in dieser Situation überhaupt eine normale zählschleife wählen? Wenn ich eh schon in der indexreinhenfolge rumspiele ist es nur eine zusätzliche Fehlerquelle, wenn die Schleife am Ende nochmals von selbst Inkrementiert.

Klar ist es besser, man verwaltet in einem solchen Fall das ganze Indexmanagement selber. Trotzdem wird es in der Praxis nicht selten vorkommen, dass bei einer normalen For-Schleife (mit automatischer Inkrementierung) im Schleifenrumpf am Index rumgespielt wird.

Aber wenn man wegen des Compilers sowieso keinen Einfluss auf diese Mikrooptimierung hat, ist es wohl auch legitim, < zu verwenden, oder?

[Fencer]

Selbstverständlich haben diese überlegungen ihre berechtigungen aber eben erst wenn (wie otze sagt) alles andere erledigt ist.

"Wer zuviel auf kleine Dinge achtet verliert den Blick für das wirklich Große"
hab ich leider vergessen wer das gesagt hat

Das ist jetzt alles was ich zu dem Thema zu sagen hab

Gute Nacht an alle

Fencer

[Nexus]

Fencer schrieb:

Selbstverständlich haben diese überlegungen ihre berechtigungen aber eben erst wenn (wie otze sagt) alles andere erledigt ist.

Wird dieser Fall überhaupt jemals eintreten?

Ich behaupte ja nicht, man solle nicht auch die wichtigen Probleme beachten. Nur denke ich, es ist auch nachvollziehbar, dass es Leute gibt, die eben auch kleinere Probleme interessieren.

Fencer schrieb:

"Wer zuviel auf kleine Dinge achtet verliert den Blick für das wirklich Große"

Dem stimme ich auch zu, man muss sich eben im Mass um solche Luxusprobleme kümmern. Aber ich befürchte deswegen nicht, dass es viele Programmierer gibt, die sich wegen solcher Angelegenheiten nicht mehr um den "wichtigeren" Code kümmern können.

[otze]

Nexus schrieb:

Aber wenn man wegen des Compilers sowieso keinen Einfluss auf diese Mikrooptimierung hat, ist es wohl auch legitim, < zu verwenden, oder?

Wurde ja nicht gesagt, dass mans nicht verwenden dürfte, nur steht das berechtigte Argument im raum, dass man sich der Iteratorsyntax anpassen sollte. Bisher konntest du auch noch kein Argument nennen, warum in einer simplen otto-normal-zählschleife ein < besser als ein != sein sollte, und solange du da kein gegenargument hast, solltest du dir überlegen, ob es nicht besser ist einfach nur der Codestruktur wegen, hier eine einheitlichkeit zwischen iteratoren, zählschleifen und zeigern reinzubringen. Der kleinste gemeinsame nenner ist dort !=.

[LOL@World]

Hier sind wieder ne ganze Menge Phollbrophyoptimierer am Werk.

[Nexus]

Ich will eigentlich nicht darauf beharren, selber nur < zu verwenden, deshalb ergreife ich hier auch nicht wirklich Partei für einen der beiden Operatoren. Ich frage eben nach, weil ich selber nicht sicher bin
Aber ich konnte mich von beiden nicht richtig überzeugen lassen; es scheinen eigentlich nur ästhetische Gründe (Konsistenz) für != zu sprechen...