schlechte angewohnheit?

CStoll

f.-th. schrieb:

Wo sind die lausigen Codetags?

Ich war mal so frei, sie zu ergänzen

@Topic: Ich finde, über den Unterschied zwischen for(;; ) und while(true) zu diskutieren ist eher eine Frage des persönlichen Stils als des praktischen Nutzens. Im Endeffekt wird bei beiden das selbe Ergebnis herauskommen - eine Endlosschleife.
Im praktischen Einsatz sind mir echte Endlosschleifen eher selten untergekommen - idR hat man eine scheinbare Endlosschleife, deren Abbruchbedingung irgendwo innen drin hinter einem if(...)break; versteckt ist. Aber wer hat, kann ja gerne mal ein praktisch relevantes Beispiel für eine (bewußt erzeugte) Endlosschleife vorführen.

Auf einem Windows-Pc sind Endlosschleifen eher weniger, vermute ich.

Aber auf Mikrokontrollern, die am Limit mit zeitkritschen Aufgaben betraut laufen, könnte ich mir so etwas vorstellen. Zur Not gibt es da ja Hardwareinterrupts.

MfG f.-th.

abc.w

Übrigens, while und for sind keine Funktionsaufrufe, daher gehört ein Leerzeichen vor die öffnende Klammer - statt dem Gefrickel

while(true)
for(;;)

verwende das hier:

while (true)
for (;;)

abc wahrscheinlich hast du

if ( )

vergessen

Halozination

nochmal zum eigentl. topic:

if(i+1>5){}

ist sowas schlecht? Oder gehört das auch zur verwaltung von konstanten ausdrücken und das programm kann am ende nur

if(i>4){}

sehen?

und nochmal meine letzte frage nach oben pushen:

Halozination schrieb:

würdet ihr sagen das:

for (int i = 0; i<12345; i++) {..}
for (int i = 10; i<54321; i++) {..}

ist schlechter als:

int i; 
for (i = 0; i<12345; i++) {..}
for (i = 10; i<54321; i++) {..}

beim 1. wird i doch einmal mehr allokiert als im 2., sowas kann in bestimmten situationen schon einiges an performance kosten oder? Da würde ich z.b. auf den vorteil ein locales i zu haben verzichten.

Nimm statt i++ auch lieber ++i, da dadurch eine sinnlose Kopie vermieden wird.
Du kannst ja mal den Unterschied zwischen post- und preincrement googlen.

bessereswissen schrieb:

Nimm statt i++ auch lieber ++i, da dadurch eine sinnlose Kopie vermieden wird.

falsch

bessereswissen schrieb:

Nimm statt i++ auch lieber ++i, da dadurch eine sinnlose Kopie vermieden wird.

richtig

falsch schrieb:

bessereswissen schrieb:

Nimm statt i++ auch lieber ++i, da dadurch eine sinnlose Kopie vermieden wird.

falsch

Bei einem int als Zähler gibt's natürlich keine unnötige Kopie, bei Iteratoren kann es anders aussehen.

volkard

Halozination schrieb:

würdet ihr sagen das:
for (int i = 0; i<12345; i++) {..}
for (int i = 10; i<54321; i++) {..}
ist schlechter als:
int i; 
for (i = 0; i<12345; i++) {..}
for (i = 10; i<54321; i++) {..}
beim 1. wird i doch einmal mehr allokiert als im 2., sowas kann in bestimmten situationen schon einiges an performance kosten oder? Da würde ich z.b. auf den vorteil ein locales i zu haben verzichten.

Nein.
Lokales i kostet eigentlich nichts. Der COmpiler muß nur zählen, wieviel Speicher die Funktion maximal braucht und kann den ganzen Speicher auf einmal anlegen. Und er kann frei wiederverwenden. Deswegen gibt es ja die Regel, daß lokale Variablen nach Definition ohne Initialisieren keinen bestimmten Wert haben. Damit der Compiler eine ganz lokale Variable auch mal herausziehen darf, ganz wie es ihm beliebt. Und so ein i wird auch gerne gleich zum Register.
Aber andersrum kann er es nicht ganz wie es ihm beliebt, das äußere i wieder lokal zu machen, um das zu schaffen, muß er schon eine ganze Menge mehr analysieren (er schafft es aber inzwischen).
Du tust also sowohl dem Programmierer einen Gefallen, der damit Fehlerchen vermeidet, als auch dem automatischen Optimierer, der besser auswählen kann.
Da ist also kein Zielkonflikt.
Es ist keine schlechte Faustregel, Variablen immer so lokal wie möglich zu machen.

Bei größeren Objekten auch hieran denken: http://fara.cs.uni-potsdam.de/~kaufmann/?page=GenCppFaqs&faq=Declare#Answ

volkard

CStoll schrieb:

Im praktischen Einsatz sind mir echte Endlosschleifen eher selten untergekommen - idR hat man eine scheinbare Endlosschleife, deren Abbruchbedingung irgendwo innen drin hinter einem if(...)break; versteckt ist.

Jupp. Echte Endlosschleifen gibt es selten. Aber while(true), while(1) und for(;;) mit innenliegendem return, trow, break oder goto bleibt unselten.

Bei mir compiliert while(true) übrigens noch nicht einmal warnungsfrei: "conditional expression is constant"

Von daher halte ich das auch eher für hässlich.

alternative schrieb:

Du darfst und solltest Konstanten auch Namen geben:
const int dingsbums = 13*5;

int main() {
  ...dingsbums...
}

#define DINGSBUMS (13*5)
tuts auch.

volkard schrieb:

Aber
while(true)
statt
for(;;)
ist nicht hübsch.

Yep, manche Compiler schmeißen bei "while(true)" eine Warnung raus.

Mox schrieb:

Bei mir compiliert while(true) übrigens noch nicht einmal warnungsfrei: "conditional expression is constant"

Von daher halte ich das auch eher für hässlich.

Bei mir: "Condition always true".
Ich verwende "while(true)" deshalb schon lange nicht mehr. Ich hasse Compiler-Warnungen.

5cript

Z schrieb:

alternative schrieb:
Du darfst und solltest Konstanten auch Namen geben:
const int dingsbums = 13*5;

int main() {
  ...dingsbums...
}
#define DINGSBUMS (13*5)
tuts auch.

Konstanten sind aber schöner als #define

Darum gibt es Streit;
Konstante Deklarationen oder
die Präprozessor-direktive #define (Hier bezogen auf z.B.:#define ival 5)
geben, so gesehen, nur einer Zahl einen Namen.
Allerdings hat const einige Vorteile:

- C++ überprüft die 'const' - Deklaration sofort, die #define - Direktive aber
erst beim ersten Benutzen des Makros.

- 'const' hat einen größeren Anwendungsbereich.

- 'const' wird nach den üblichen C++ -schen Gültigkeitsbereich - Regeln und einer C++ -schen Syntax angewandt und geprüft, die #define - PpD allerdings nicht - Sie ist überall gültig (also in dem Sinne nicht direkt ein Nachteil) und hat
eine eigene Syntax (ob auch jeder versteht, was das dann alles für einen
Unterschied macht, weiß ich nicht).

Wenn wir schon über for(;;) und while(true) diskutieren, oder ist es doch for (;;) und while (true) diskutieren, könnten wir dabei noch diskutieren, ob man tabs oder spaces zum Einrücken verwenden soll. Und wenn spaces, dann wie viele? Das ist doch auch eine sinnvolle Diskussion. Zumindest verbringen viele Programmierer viel Zeit damit. Dann muss es doch wichtig sein! Auch wäre es wichtig zu diskutieren, ob ein if immer eine geschweifte Klammer benötigt. Ach es gibt so viele ach so wichtige Sachen zu diskutieren, dass man gar nicht dazu kommt, wirklich produktiv zu sein.

cooky451

Ich mache mal den Anfang:
2 Spaces zum einrücken und if/while/for brauchen nicht immer eine Klammer.

EOutOfResources

cooky451 schrieb:

2 Spaces zum einrücken und if/while/for brauchen nicht immer eine Klammer.

Dito.

abc.w

Genau, wozu überhaupt Leerzeichen Jeder darf sich austoben, wie er will. Hauptsache, der Compiler kommt damit klar. Write-Only-Source-Code (in Anspielung auf Write-Only-Memory...)