zählt diese for Schleife 10mal?

[Martin (Gast)]

Hallo,

ich beschäftige mich gerade mit den Schleifentypen.

Diese for-Schleife sollte doch 10mal durchlaufen werden?

Blockiert die for-schleife bei einem Thread auch alles, so wie die while 
schleife?

for(wi=0; wi=9; wi++)
{

}

Gruß Martin

[for-next (Gast)]

nein!

[MaWin (Gast)]

> Diese for-Schleife sollte doch 10mal durchlaufen werden?

Nein, natürlich nicht.
Du solltest noch mal Zuweisung und Vergleich nachschlagen.

> Blockiert die for-schleife bei einem Thread auch alles,
> so wie die while schleife?

Sie ist wie die while-Schleife, aber ob's blockiert liegt
an dir.

[for (Gast)]

Martin schrieb:
> Diese for-Schleife sollte doch 10mal durchlaufen werden?

Nein, es gibt einen Unterschied zwischen "=" und "==".

[Florian (Gast)]

Auch mit == wirds nicht gehen.

An den Fragesteller: Lies nochmal nach, was der mittlere Ausdruck (dein 
wi=9) steuert.

[Timmo H. (masterfx)]

for schrieb:
> Nein, es gibt einen Unterschied zwischen "=" und "==".
zumal hier ein "<" oder "<=" angebracht wäre

[DirkB (Gast)]

Die for-Schleife wird solange durchlaufen, wie die Bedingung (in der 
Mitte) wahr ist.

Da du am Anfang schon wi auf 0 setzt, ist die Bedingung (auch wenn du 
sie mit == schreibst) falsch.

Darum for(wi=0; wi<10; wi++) und du kannst sehen, dass sie 10 mal 
durchlaufen wird.

[g457 (Gast)]

> Diese for-Schleife sollte doch 10mal durchlaufen werden?

Nope, dasdas

> for(wi=0; wi=9; wi++)

ist eine Endlosschleife.

HTH

[Tilo (Gast)]

Wieso sollte das eine Endlosschleife sein?

[Sam .. (sam1994)]

wi=9 ist immer wahr

[Klaus W. (mfgkw)]

Weil der Ausdruck immer wahr ist.

[g457 (Gast)]

> Wieso sollte das eine Endlosschleife sein?

Weil 'wi=9' in

> for(wi=0; wi=9; wi++)

immer [1] zu wahr auswertet (und des TOs Schleifenkörper ziemlich leer 
ist).

HTH

[1] ich setzt jetzt mal einen Integertyp voraus für wi. In C++ kann man 
da natürlich Sauereien anstellen..

[Peter D. (peda)]

Ich schreibe immer die Anzahl als erster Ausdruck, das ist am besten 
lesbar. Auch kennen die Compiler diese Schreibweise und optimeren das 
sehr gut, z.B. zu DJNZ beim 8051.

for( i = 10; i; i-- ){
...
}

Peter

[Johann L. (gjlayde)]

Peter Dannegger schrieb:
> Auch kennen die Compiler diese Schreibweise und optimeren
> das sehr gut, ...

Es gibt Compiler, die anhand der "Schreibweise" optimieren?

[Rolf M. (rmagnus)]

Sie erkennen die aus dieser Schreibweise resultierende Kombination aus 
Dekrementierung und einem Vergleich mit 0. Da in der Regel das Dekrement 
auch schon die Flags setzt, kann man die Vergleichs-Instruktion 
weglassen, und das tun die Compiler dann auch.

[Heinz (Gast)]

Da es sich hier offensichtlich um eine kopfgesteuerte Schleife handelt, 
die nur für ehem. Basic-user von K&R eingerichtet wurde, könnte man auf 
die Idee kommen, dieses for() Konstrukt für sich über den Haufen zu 
werfen und im Sinne einer while-Schleife zu kodieren. Es ist ja nix 
anderes als das. Dann gäbe es auch nicht so viele Fragen hier im Forum 
über die korrekte Schreibweise dieser Parameter.
Also: (ich bin nur Pascal-Programmierer)

laufvar = 0;
while (laufvar <[=] ende {

  laufvar++;
}

Ich finde, dass das einfach übersichtlicher ist.
In Pascal schreibe ich:

laufvar := 0;
while (laufvar <[=] ende) then
  begin
    ...
    inc(Lauvar);
  end;

Ich habe beides(for.. und while(mit vorheriger Initalisierung der 
Laufvariablen)) in einem C-Programm versucht. Das generierte Hex-File 
war in beiden Fällen gleich groß.

[Nico S. (nico22)]

Johann L. schrieb:
> Peter Dannegger schrieb:
>> Auch kennen die Compiler diese Schreibweise und optimeren
>> das sehr gut, ...
>
> Es gibt Compiler, die anhand der "Schreibweise" optimieren?

Ich wollte diese Aussage selbst tatsächlich auch nicht glauben. Daher 
hier mal harte Fakten (gcc (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) 4.5.3)

Ohne Optimierung:

int main(void) {
   0:  55                     push   %rbp
   1:  48 89 e5               mov    %rsp,%rbp

        int i;

        for(i = 0; i < 50; i++) {
   4:  c7 45 fc 00 00 00 00   movl   $0x0,-0x4(%rbp)
   b:  eb 04                  jmp    11 <main+0x11>
   d:  83 45 fc 01            addl   $0x1,-0x4(%rbp)
  11:  83 7d fc 31            cmpl   $0x31,-0x4(%rbp)
  15:  7e f6                  jle    d <main+0xd>
    asm("":::"memory");
        }

        for(i = 50; i; i--) {
  17:  c7 45 fc 32 00 00 00   movl   $0x32,-0x4(%rbp)
  1e:  eb 04                  jmp    24 <main+0x24>
  20:  83 6d fc 01            subl   $0x1,-0x4(%rbp)
  24:  83 7d fc 00            cmpl   $0x0,-0x4(%rbp)
  28:  75 f6                  jne    20 <main+0x20>
    asm("":::"memory");
        }

        return 0;
  2a:  b8 00 00 00 00         mov    $0x0,%eax
}
  2f:  c9                     leaveq 
  30:  c3                     retq

Hah! Zu früh gefreut. Schon mit O2 hingegen macht es wirklich einen 
Unterschied:

int main(void) {
   0:  b8 32 00 00 00         mov    $0x32,%eax
   5:  0f 1f 00               nopl   (%rax)

        int i;

        for(i = 0; i < 50; i++) {
   8:  83 e8 01               sub    $0x1,%eax
   b:  75 fb                  jne    8 <main+0x8>
   d:  b8 32 00 00 00         mov    $0x32,%eax
  12:  66 0f 1f 44 00 00      nopw   0x0(%rax,%rax,1)
    asm("":::"memory");
        }

        for(i = 50; i; i--) {
  18:  83 e8 01               sub    $0x1,%eax
  1b:  75 fb                  jne    18 <main+0x18>
    asm("":::"memory");
        }

        return 0;
}
  1d:  31 c0                  xor    %eax,%eax
  1f:  c3                     retq

Da das mov/nopw aber ja schon zur zweiten Schleife gehört, ist es doch 
wieder ohne Unterschied :-/

[Heinz (Gast)]

Nico Sch. schrieb:
> Das hätte ich nicht erwartet.
Du hast das mit einem Compiler for x86 getestet. Kannst du meine o.a. 
Idee auch noch mal verifizieren? Müsste sonst Turbo C wieder aus dem 
Grab holen :-)

[MaWin (Gast)]

> dieses for() Konstrukt für sich über den Haufen zu
> werfen und im Sinne einer while-Schleife zu kodieren.

Könnte man.

Man könnte auch GOTOs einbauen, wenn man
strukturiertes Programmieren nicht versteht.

[Heinz (Gast)]

MaWin schrieb:
> Man könnte auch GOTOs einbauen, wenn man
> strukturiertes Programmieren nicht versteht.
Sei nicht so streng. War ja nur als Hilfe für die gedacht, die es bis 
heute nicht verstanden haben :-).

[Nico S. (nico22)]

@Heinz:

  0:  b8 32 00 00 00         mov    $0x32,%eax
   5:  0f 1f 00               nopl   (%rax)

        int i = 0;

  while(i < 50) {
   8:  83 e8 01               sub    $0x1,%eax
   b:  75 fb                  jne    8 <main+0x8>
    asm("":::"memory");
    i++;
  }

Also wieder mov, nop*, sub und jne. Tut sich nichts. O2.

[Heinz (Gast)]

Danke dir, Nico!

[Andreas B. (andreas_b77)]

Ob das Zählen aufwärts oder abwärts unterschiedlich optimiert werden 
kann, hängt grundsätzlich vom Code in der Schleife ab. Der Compiler kann 
zwar bei konstanten Bedingungen erkennen, wie viele Durchläufe es gibt 
und dementsprechend optimieren.

Das hilft aber nichts, wenn der Code in der Schleife den Zähler 
undurchsichtig verwendet, denn dann muss der Compiler sich 
standardkonform verhalten. Bei "i=0; i<50; i++" heißt das, das zuerst 
i=0 ausgeführt wird, dann i=1, dann i=2, ... Und das 
"asm("":::"memory");"  verhindert jede Optimierung, denn es schreibt 
vor, dass alle Werte von Variablen vorher davor in ihre Speicherstellen 
geschrieben werden und danach wieder geladen werden (da sie sich 
verändert haben könnten). Damit wird wieder eine Sequentialisierung 
erzwungen.

Wenn man das nicht erzwingt, kann der Compiler das sehr wohl umformen:

void g(void);

void f(void)
{
  int i;

  for (i = 0; i < 50; i++)
    g();
}

Hier die Ausgabe vom gcc für ARM mit -O2:

00000000 <f>:
   0:  e92d4010   push  {r4, lr}
   4:  e3a04032   mov  r4, #50  ; 0x32
   8:  ebfffffe   bl  0 <g>
   c:  e2544001   subs  r4, r4, #1
  10:  1afffffc   bne  8 <f+0x8>
  14:  e8bd4010   pop  {r4, lr}
  18:  e12fff1e   bx  lr

Man sieht, er zählt abwärts und nutzt das Zero Flag statt einem extra 
Vergleich.

[Andreas B. (andreas_b77)]

Oder in 3 Varianten:

void g(void);

void f(void)
{
  int i;

  for (i = 0; i < 50; i++)
    g();

  for (i = 50; i > 0; i--)
    g();

  for (i = 100; i < 200; i += 2)
    g();
}

Dieses Mal als gcc -S Ausgabe:

f:
  @ Function supports interworking.
  @ args = 0, pretend = 0, frame = 0
  @ frame_needed = 0, uses_anonymous_args = 0
  stmfd  sp!, {r4, lr}
  mov  r4, #50
.L2:
  bl  g
  subs  r4, r4, #1
  bne  .L2
  mov  r4, #50
.L3:
  bl  g
  subs  r4, r4, #1
  bne  .L3
  mov  r4, #50
.L4:
  bl  g
  subs  r4, r4, #1
  bne  .L4
  ldmfd  sp!, {r4, lr}
  bx  lr

Und wenn er noch die Inhalte der Schleifen vergleichen würde, könnte er 
das alles in eine Schleife packen… Aber das wird in realem Code wohl so 
selten auftreten, dass sich eine solche Optimierung nicht lohnt.

[Karl H. (kbuchegg)]

Heinz schrieb:
> Da es sich hier offensichtlich um eine kopfgesteuerte Schleife handelt,
> die nur für ehem. Basic-user von K&R eingerichtet wurde,

Äh, nein.

Der Sinn der Sache in C war es, das 'Pattern'

  Initialisierung;
  while( Bedingung ) {
    Statement;
    Increment;
  }

so zu formulieren, dass die für die Schleifensteuerung wesentlichen 
Teile (Initialisierung, Bedingung und Increment) an EINER Stelle 
beisammen bleiben und nicht quer über den Code verstreut werden. Eben

  for( Initialisierung; Bedingung; Increment )
    Statement

Das hat also ganz handfeste softwaretechnische Gründe und mit Basic 
schon gleich gar nichts zu tun. For-Schleifen in Basic funktionieren 
ganz anders und zb in Fortran (wo das DO-Schleife heißt) wieder anders. 
Lass dich nicht vom Schlüsselwort blenden! Nur weil Dinge in 
verschiedenen Sprachen dasselbe Schlüsselwort benutzen, heißt das nicht, 
dass die Funktionalität identisch ist.

> die Idee kommen, dieses for() Konstrukt für sich über den Haufen zu
> werfen und im Sinne einer while-Schleife zu kodieren. Es ist ja nix
> anderes als das.

Richtig. Könnte man

> Dann gäbe es auch nicht so viele Fragen hier im Forum
> über die korrekte Schreibweise dieser Parameter.

Ist aber trotzdem der falsche Ansatz.
for hat schon seinen Sinn. Das man in der Lernphase mal Fehler macht ist 
nichts neues und auch nicht ungewöhnlich. Deswegen ist es aber nicht 
zielführend Dinge links liegen zu lassen. Nächstens kommst du dann mit 
"Da Funktionen so kompliziert sind kann man auch den Funktionscode 
direkt an der Aufrufstelle einsetzen. Ist ja im Prinzip auch nichts 
anderes."