Hallo Zusammen,
ich habe ein etwas komisches Verhalten mit einer for-Schleife:
unsinged char i;
for(i=0;i<256;i++)
dooo();
endet in einer Endlosschleife! Kann mir das jemand erklären?
Danke!
Ja.
i ist ein unsigned char (nicht unsinged char, vermute ich)
und kann als solches Werte von 0 bis 255 annehmen.
Hat es bereits den Wert 255 und man erhöht es nochmals
wird es wieder 0.
Damit ist i<256 immer erfüllt.
Ok Ok.. mir ist klar das unsigned char als [0; 255] definiert ist!
Ich habe nur dem Compiler soviel "Intelligenz" unterstellt, dass er ein
CP Rxy, 0xFF
BREQ adr
erstellt!
Macht er also nicht...
danny schrieb:
> Ich habe nur dem Compiler soviel "Intelligenz" unterstellt, dass er ein> CP Rxy, 0xFF> BREQ adr> erstellt!>Macht er also nicht...
Seufz!
@Mmmh : Gibts es irgend einen "Compiler" der mir deine "Seufz!"
übersetzen kann ;)
BTW:
for(i=0;i<=255;i++)
ist ja genau das Gleiche wie meine erste Schleife...
Zum Glück macht er das nicht. Ich will immernoch durch mein Programm
bestimmen, was es zu tun hat und nicht der Compiler.
Davon abgesehen ist unsigned char als [0..255] und nicht als [0; 255]
definiert. (Wobei ich mir grad nicht sicher bin, ob ein char
grundsätlich 8 Bit hat oder ob es bei anderen Sprachen/Systemen auch
noch unterschiede gibt.
Fabian schrieb:
> Zum Glück macht er das nicht. Ich will immernoch durch mein Programm> bestimmen, was es zu tun hat und nicht der Compiler.>> Davon abgesehen ist unsigned char als [0..255] und nicht als [0; 255]> definiert. (Wobei ich mir grad nicht sicher bin, ob ein char> grundsätlich 8 Bit hat oder ob es bei anderen Sprachen/Systemen auch> noch unterschiede gibt.
Ja, auf manchen System hat ein char nur 7 Bits.
Gruß,
Bernd
>BTW:>for(i=0;i<=255;i++)>ist ja genau das Gleiche wie meine erste Schleife...
Würde ich nach kurzen Nachdenken auch meinen...
Ich liebe for-Schleifen eh nicht. Mit while sieht man irgendwie klarer.
Übrigens hatte Wirth FOR aus seinem ersten Oberon-Compiler verbannnt,
bei Oberon-2 kam das FOR dann aber doch wieder rein.
Hallo,
Mmmh schrieb:
> danny schrieb:>> Ich habe nur dem Compiler soviel "Intelligenz" unterstellt, dass er ein>> CP Rxy, 0xFF>> BREQ adr>> erstellt!>>Macht er also nicht...>> Seufz!
Er macht, was Du ihm sagst...
Bestenfalls wäre es also CPI Rxy, 256 und das ginge schlecht.
Springen müßter er mit BRLO, Du hast ja nicht
for (i=0; i = 255; i++) bei ihm bestellt, das würde Dein obiges
Konstrukt ergeben können.
Ein Computer macht nicht immer das, was er soll.
Er macht aber IMMER, was man ihm sagt.
Gruß aus Berlin
Michael
Stefan Salewski schrieb:
>>for(i=0;i<256;i++)>> dooo();>> Ich hätte eh>> for(i=0;i<=255;i++)>> geschrieben -- 256 passt ja nicht mehr in ein Byte.
Dir ist aber schon klar, dass das genau so wenig funktioniert? Die
Bedingung ist auch immer wahr.
Autor: Simon K. (simon)
>Dir ist aber schon klar, dass das genau so wenig funktioniert? Die>Bedingung ist auch immer wahr.
Ja, wie ich weiter oben schon schrieb, nach etwas nachdenken schon.
Michael U. schrieb:
> for (i=0; i = 255; i++) bei ihm bestellt, das würde Dein obiges> Konstrukt ergeben können.
Bevor er das ausprobiert, kleine Korrektur:
for (i=0; i == 255; i++)
;-) <-- das ist ein Smiley, kein Code!
eklige Tunke schrieb:
> Michael U. schrieb:>> for (i=0; i = 255; i++) bei ihm bestellt, das würde Dein obiges>> Konstrukt ergeben können.> Bevor er das ausprobiert, kleine Korrektur:> for (i=0; i == 255; i++)> ;-) <-- das ist ein Smiley, kein Code!
Aber das macht doch auch keinen Sinn, die Schleife würde nie ausgeführt
werden, da bereits 0 != 255 ist.
Bernd O. schrieb:
> Ja, auf manchen System hat ein char nur 7 Bits.
Das wäre allerdings nicht C-Standard-konform. Ein char muss
mindestens 8 bits haben, um eine konforme Implementierung zu
erreichen.
Es können allerdings mehr Bits sein, es gibt beispielsweise konforme
Implementierungen auf irgendeinem DSP, der als kleinste adressierbare
Einheit einen 32-bit-Integer hat. Dort ist ein char dann auch 32
bits breit (aber sizeof(char) ist trotzdem 1!, denn das ist so
definiert).
danny schrieb:
> Ich habe nur dem Compiler soviel "Intelligenz" unterstellt, [...]
Die Intelligenz des Compilers besteht darin, dass er dir bei
eingeschalteten Warnungen (-Wall -Wextra ist immer eine gute Idee)
sagt, dass du da soeben eine Endlosschleife von ihm verlangt hast
("comparison is always true due to limited range of operands" oder
sowas).
eklige Tunke schrieb:
> Michael U. schrieb:>> for (i=0; i = 255; i++) bei ihm bestellt, das würde Dein obiges>> Konstrukt ergeben können.> Bevor er das ausprobiert, kleine Korrektur:> for (i=0; i == 255; i++)
Jap, aus der Immer-Schleife eine Niemals-Schleife zu machen, hilft ihm
bestimmt weiter. ;-)
danny schrieb:
> @Mmmh : Gibts es irgend einen "Compiler" der mir deine "Seufz!"> übersetzen kann ;)
Keine Ahnung. Aber ich gebe Dir eine.
Seufz hat einen Grundton von "Urgs" mit einer deutlichen
"Umpf"-Komponente.
Und bevor Du weiterfragst: Es sind alles Elefanten. Bis ganz unten.
Stefan Ernst schrieb:
> eklige Tunke schrieb:>> Michael U. schrieb:>>> for (i=0; i = 255; i++) bei ihm bestellt, das würde Dein obiges>>> Konstrukt ergeben können.>> Bevor er das ausprobiert, kleine Korrektur:>> for (i=0; i == 255; i++)>> Jap, aus der Immer-Schleife eine Niemals-Schleife zu machen, hilft ihm> bestimmt weiter. ;-)
Scheiße... ;-)
Damit ich doch Recht habe:
von einer Immer-Schleife zu einer anderen Immer-Schleife und dann zu
einer Nimmer-Schleife... ;-)
>Aber das macht doch auch keinen Sinn,
Dachte ich mir auch gerade...
Aber mit einer while-Schleife sollte man doch bei eimem Wertevorrat von
0 bis 255 256 Wiederholungen realisieren können -- sowohl auf- als
absteigend. Oder täusche ich mich erneut?
Hallo,
Stefan Ernst schrieb:
> eklige Tunke schrieb:>> Michael U. schrieb:>>> for (i=0; i = 255; i++) bei ihm bestellt, das würde Dein obiges>>> Konstrukt ergeben können.>> Bevor er das ausprobiert, kleine Korrektur:>> for (i=0; i == 255; i++)>> Jap, aus der Immer-Schleife eine Niemals-Schleife zu machen, hilft ihm> bestimmt weiter. ;-)
von meinem Tipfehler abgesehen: ich habe nicht gesagt, daß es in seinem
Sinn funktioniert, ich habe nur gesagt, das könnte besagten ASM-Code
erzeugen:
>> CP Rxy, 0xFF>> BREQ adr
;-))
Gruß aus Berlin
Michael
>Du täuschst dich
Ich dachte etwas so:
i=0;
while (i++ != 0) {}
i=255;
while (i-- != 255) {}
Man nimmt also den Überlauf in kauf. Ich denke schon, dass das
funktioniert.
Wobei ich mir nicht sicher bin, ob man eventuell Pre-Increment schreiben
müsste, also ++i bzw. --i ?. Ja, ich liebe C nicht wirklich.
Stefan Salewski schrieb:
> Ich dachte etwas so:>> i=0;> while (i++ != 0) {}>> i=255;> while (i-- != 255) {}>> Man nimmt also den Überlauf in kauf. Ich denke schon, dass das> funktioniert.
Warum denkst du nur und probierst es nicht aus?
yalus Lösung geht.
yalu schrieb:
> Das ist zwar nicht klinisch sauber, da der Additionsüberlauf genutzt> wird, aber auf Mikrocontrollern erlaubt :)
Da du ein uint8_t benutzt hast, ist das sogar "klinisch sauber".
Der Überlauf einer vorzeichenlosen Zahl nach 0 ist definiert, und
bei einem uint8_t ist auch klar, dass der Typ genau 8 bits breit
ist.
es geht nicht mit nur einer Abfrage (egal ob do while, while oder for)
mit einem(!) 8 bit Zähler (256 Möglichkeiten) eine Schleife mit 256
Durchläufen zu bauen.
Denn bei welchem Wert des Zählers soll er aufhören? 256 gibts nicht und
alles andere wird schon vor dem 256. Durchlauf durchlaufen (was ein
Wortspiel).
Viel Spaß beim Suchen der Möglichkeiten :-)
Flo schrieb:
> es geht nicht mit nur einer Abfrage (egal ob do while, while oder for)> mit einem(!) 8 bit Zähler (256 Möglichkeiten) eine Schleife mit 256> Durchläufen zu bauen.> Denn bei welchem Wert des Zählers soll er aufhören? 256 gibts nicht und> alles andere wird schon vor dem 256. Durchlauf durchlaufen (was ein> Wortspiel).>> Viel Spaß beim Suchen der Möglichkeiten :-)
Siehe ein Beitrag über deinem. Das Überlaufbit fungiert als 9. Bit.
Dass geht aber nur mit einer Programmiersprache, mit der du auf das
Carrybit zugreifen darfst.
Ist in C/C++ nicht der Fall / nicht zu empfehlen, da die Abfragen nicht
immer unmittelbar nach den Operationen kommen, deren Ergebnis du haben
willst.
Rolf Magnus schrieb:
> Das Überlaufbit hat damit nichts zu tun. Man benutzt auch keine 9 Bits.
Entweder du erklärst das, oder ich unterstelle dir, dass du yalus
Beitrag nicht gelesen hast.
EDIT: Ok, ich muss das noch mal ausprobieren bei Gelegenheit. Sicher,
dass bei yalu's Methode 256 Iterationen gemacht werden?
Bin leider gerade in Klausurübungen vertieft.
Autor: Rolf Magnus (Gast) schrieb:
>Das Überlaufbit hat damit nichts zu tun. Man benutzt auch keine 9 Bits.
Das wollte ich auch gerade schreiben, auch wenn es etwas nach
Korintenkackerei klingen mag.
An yalus Beispiel sieht man, dass man zwar den Überlauf ausnutzt, aber
kein Überlauf-Bit abfragen muss.
Jörg Wunsch schrieb:
> Ein char muss> mindestens 8 bits haben, um eine konforme Implementierung zu> erreichen.>> Es können allerdings mehr Bits sein, es gibt beispielsweise konforme> Implementierungen auf irgendeinem DSP,
Nicht auf irgendeinem, es gibt mehrere, z.B. TMS320C3x oder ADSP21020
und noch andere. Das sind zwar alles seeeehr alte Dinger, aber immer
noch viel benutzt in gewissen Technik-Bereichen. :-/
Hat aber einen Vorteil, eine Exception wegen "unaligned access" passiert
dort nicht. :-) Ein Adressinkrement sind dort immer 32 Bit.
> der als kleinste adressierbare> Einheit einen 32-bit-Integer hat. Dort ist ein char dann auch 32> bits breit (aber sizeof(char) ist trotzdem 1!, denn das ist so> definiert).
Genauso verhält es sich.
> uint8_t i;
Soetwas gibt es dann auch nicht. Wenn man einen Zähler bis 255 braucht,
dann kann man nicht mit dem Überlauf arbeiten, sondern man muß das
explizit kodieren, ansonsten Pech gehabt :-) Der Compiler ist nicht so
schlau und setzt das selber um.
>> Das Überlaufbit hat damit nichts zu tun. Man benutzt auch keine 9 Bits.>> Entweder du erklärst das, oder ich unterstelle dir, dass du yalus> Beitrag nicht gelesen hast.
Wo steht denn dort was von einem Überlaufbit? Man nutzt aus, daß ein
8-Bit-Integer mit dem Wert von 255 bei einem Inkrement auf 0 springt
(Überlauf). Mit dem Überlauf-Flag hat das aber nichts zu tun. Das gibt
es in C auch gar nicht. Es wird im Prozessor zwar bei einem Überlauf
gesetzt, aber für diese Schleife überhaupt nicht benutzt. Die würde ohne
Existenz dieses Flags genauso funktionieren.
Flo schrieb:
> es geht nicht mit nur einer Abfrage (egal ob do while, while oder for)> mit einem(!) 8 bit Zähler (256 Möglichkeiten) eine Schleife mit 256> Durchläufen zu bauen.> Denn bei welchem Wert des Zählers soll er aufhören? 256 gibts nicht und> alles andere wird schon vor dem 256. Durchlauf durchlaufen (was ein> Wortspiel).
Der Trick besteht darin, eine post-checked Loop zu benutzen. Bei dieser
wird der erste Schleifendurchlauf ausgeführt, obwohl die Bedingung
(i!=0) falsch ist, da die Abfrage ja erst am Ende kommt. Dieser
zusätzliche Schleifendurchlauf macht die 256 voll.
Bei einer pre-checked Loop (While- oder For-Schleife) stimmt deine
Überlegung, deswegen verliefen auch Stefan Salewskis Versuche mit der
While-Schleife im Sand.
doc schrieb:
> Und siehe da, es geht mit 8 Bit.
Das ist doch aber nichts anderes als yalus Variante, nur dass er
das Inkrementieren in die while-Klausel verlegt hat (als Präfix-
Operator).
900ss D. schrieb:
> Nicht auf irgendeinem, es gibt mehrere, z.B. TMS320C3x oder ADSP21020> und noch andere. [...]
Ich kannte sie gerade nicht mit Vornamen, daher habe ich das etwas
anonymisiert geschrieben. ;-)
>> uint8_t i;>> Soetwas gibt es dann auch nicht.
Richtig, daher ist diese Schreibweise auch sicher ("unsigned char i;"
wäre es nicht). Wenn man nicht "exakt 8 bits breit" meint, sollte
man sich ohnehin besser angewöhnen, "uint_fast8_t" statt "uint8_t"
zu benutzen. Dann hat der Compiler die Freiheit, auf einem 32-bit-
Prozessor auch 32 bits stattdessen zu nutzen, wenn diese schneller
sind (bspw. ein komplettes 32-bit-Register auf einer 32-bit-CPU).
doc schrieb:
>> Und siehe da, es geht mit 8 Bit.>Das ist doch aber nichts anderes als yalus Variante,
Deshalb schrieb ich ja auch :
>Exakt
:-)
Habs nur etwas deutlicher formuliert.
Jörg Wunsch schrieb:
> Richtig, daher ist diese Schreibweise auch sicher ("unsigned char i;"> wäre es nicht).
Ja, ich nutze eigentlich auch nur noch die "neuen" Typen. Und es gibt
sooo viele Leute, die das nicht machen. Gestern hat man mir Code aus dem
Jahre 2000 vorgelegt, den ich jetzt adaptieren soll.
Dort steht dann z.B. drin:
#define BIT_AND &
#define LOG_AND &&
#define BIT_OR |
#define LOG_OR ||
if( status BIT_AND BIT_RX )
machWas();
Der ganze Code ist mit solchen Makros vollgestopt. Kann man nicht lesen.
Mir ist nichts mehr eingefallen :-(
Ähh ja, Offtopic :-)
> Wenn man nicht "exakt 8 bits breit" meint
Schön formuliert :-)
doc schrieb:
> Das mit dem gedachten Carry hatte schon was richtiges :-)
Mit dem Carry hat das wirklich nichts zu tun. Für einen AVR wird die
Do-Schleife bspw. so übersetzt:
1
ldi r24,lo8(0)
2
.L2:
3
; ...
4
subi r24,lo8(-(1))
5
brne .L2
Das einzige Prozessorflag, das abgefragt wird, ist das Zero-Flag.
> Das mit dem gedachten Carry hatte schon was richtiges :-)>Mit dem Carry hat das wirklich nichts zu tun.
Stimmt, da wird kein Carry-Bit benutzt. Deswegen ist es ja auch nur
GEDACHT.
Hätte ich es anders gemeint, hätte ich das auch anders geschrieben.
Gedacht als Denkhilfe halt..
grummel...
Ich geh lieber programmieren... tschö.
900ss D. schrieb:
> #define BIT_AND &> #define LOG_AND &&> #define BIT_OR |> #define LOG_OR ||
Das erinnert mich an ein Stück Software namens "team". War ein
wirklich interessantes Stück von der Funktion: ein Ringpuffer
zur Zwischenspeicherung von Daten für ein Magnetbandgerät, damit
das Band am gleichmäßigen Laufen ("streaming") bleibt. Anders als
das "creeping featurism"-Teil von GNU (heißt wohl "buffer") kam
team mit den Möglichkeiten eines V7 UNIX aus: für jeden der
umzuschaltenden Puffer wurde ein eigener Prozess per fork()
erzeugt, alle diese Prozesse haben sich die Deskriptoren für stdin
(Quell-Datenstrom) und stdout (Magnetband) geteilt, und die
Synchronisation zwischen den Prozessen (wer liest und wer schreibt)
erfolte über Pipes zwischen diesen. Wirklich "cool", wie man das
heutzutage nenne würde.
Aber der Sourcecode. Oh Gott. :-)
1
# define call (void)
2
# define were if
3
# define fast register
4
# define global /* extern */
5
# define local static
6
# define when break; case
7
# define otherwise break; default
8
# define mode(which,name) typedef which name name; which name
Aber wozu denkst du's dir denn, wenn's gar nicht verwendet wird?
duck
900ss D. schrieb:
> Dort steht dann z.B. drin:>> #define BIT_AND &> #define LOG_AND &&> #define BIT_OR |> #define LOG_OR ||>> if( status BIT_AND BIT_RX )> machWas();
Der wußte wohl nicht, daß es einen Standard-C-Header gibt, der dafür
extra schon Makros mitbringt.
http://en.wikipedia.org/wiki/Iso646.h
danny schrieb:
> Ok Ok.. mir ist klar das unsigned char als [0; 255] definiert ist!>> Ich habe nur dem Compiler soviel "Intelligenz" unterstellt, dass er ein> CP Rxy, 0xFF> BREQ adr> erstellt!>> Macht er also nicht...
Bevor Du die Qualitaet des Compilers anzweifelst solltest Du erst einmal
semantisch korrekten Code schreiben, was haeltst Du davon?
Michael G. schrieb:
> danny schrieb:>> Ok Ok.. mir ist klar das unsigned char als [0; 255] definiert ist!>>>> Ich habe nur dem Compiler soviel "Intelligenz" unterstellt, dass er ein>> CP Rxy, 0xFF>> BREQ adr>> erstellt!>>>> Macht er also nicht...>> Bevor Du die Qualitaet des Compilers anzweifelst solltest Du erst einmal> semantisch korrekten Code schreiben, was haeltst Du davon?
Danke für deinen Kommentar.
Jörg Wunsch schrieb:
> Aber der Sourcecode. Oh Gott. :-)
Ja das genauso schlimm :-)
Rolf Magnus schrieb:
> Der wußte wohl nicht, daß es einen Standard-C-Header gibt, der dafür> extra schon Makros mitbringt.
Da schlägt es einen nieder. Das gibt es sogar vorgekaut ;-)
Nun ja, nicht mein Stil. Kann man sich wohl drna gewöhnen, wenn man es
muß.
Jörg Wunsch schrieb:
> Es können allerdings mehr Bits sein, es gibt beispielsweise konforme> Implementierungen auf irgendeinem DSP, der als kleinste adressierbare> Einheit einen 32-bit-Integer hat. Dort ist ein char dann auch 32> bits breit (aber sizeof(char) ist trotzdem 1!, denn das ist so> definiert).
D. h. folgender Code würde nicht wie erwartet funktionieren?
1
#define BUFFSIZE 128
2
char*buff=malloc(sizeof(char)*BUFFSIZE);
3
if(buff){
4
uint8_ti;
5
for(i=0;i<BUFFSIZE;i++){
6
*(buff+i)=42;
7
}
8
}
weil malloc nur 128 Byte reserviert, aber 128 mal in 32 Bit Schritten
weiter gegangen wird?
Falsch.
Genauer gesagt: der Code würde arbeiten wie ich es erwarte.
Was du erwartest weiß ich nicht genau :-)
Auf einem solchen System ist doch wie gesagt ein char
32 Bit groß (also nicht ein Byte, sondern 4).
Mit sizeof(char) ist dort 1, sizeof(char)*128 ist 128.
Also reserviert malloc(sizeof(char)*BUFFSIZE) dann
128 char, also 128*4 Byte.
Mit *(buff+0) bis *(buff+127) greift man auf jeweils eines
dieser 4-Byte-char zu und alles ist in Ordnung.
Außer daß jede 42 in 4 Byte gespeichert ist, weil ein char
ja so groß ist.
Malte __ schrieb:
> Jörg Wunsch schrieb:>> Es können allerdings mehr Bits sein, es gibt beispielsweise konforme>> Implementierungen auf irgendeinem DSP, der als kleinste adressierbare>> Einheit einen 32-bit-Integer hat. Dort ist ein char dann auch 32>> bits breit (aber sizeof(char) ist trotzdem 1!, denn das ist so>> definiert).>> D. h. folgender Code würde nicht wie erwartet funktionieren?
Kommt auf deine Erwartungen an :-)
>
1
>#defineBUFFSIZE128
2
>char*buff=malloc(sizeof(char)*BUFFSIZE);
3
>if(buff){
4
>uint8_ti;
5
>for(i=0;i<BUFFSIZE;i++){
6
>*(buff+i)=42;
7
>}
8
>}
9
>
> weil malloc nur 128 Byte reserviert,
warum sollte es?
Hinweis. Der C-Standard weiß eigentlich nichts von Bytes, so wie wir den
Begriff benutzen. Im C-Standard ist Byte synonym zu sizeof(char) zu
sehen. malloc allokiert in dem Fall 128 C 'Bytes', die auf diesem System
dann 512 unsere üblichen 8 Bit Bytes entsprechen. In diesem Sinne ist
die übliche Beschreibung für malloc, dass es 'Bytes' allokiert
eigentlich nicht richtig. malloc allokiert die angegebene Anzahl
char-Einheiten :-)
Bleifuss schrieb:
> Mit Pointercasting kann man sich dann aber eine rostige Scud durch den> Fuss schiessen.
Auch nicht.
Das ist alles so abgestimmt, dass ein Rädchen ins andere greift :-)
Einzig und alleine auf Hardware-Bytes kann man dann nicht mehr direkt
zugreifen.
ALlerdings macht man so etwas ja auch nicht nach Lust und Laune.
Meistens stecken da Hardware-Restiktionen dahinter. D.h. dass es bei
besagtem DSP höchst wahrscheinlich gar nicht möglich ist, auf 8 Bit
Bytes im Speicher zuzugreifen.
Klaus Wachtler schrieb:
> Genauer gesagt: der Code würde arbeiten wie ich es erwarte.> Was du erwartest weiß ich nicht genau :-)
Ich denke meist kann man von einem Code erwarten, dass nicht das Ziel
ist in nicht zugewiesenen Speicher zu schreiben ;-)
Karl heinz Buchegger schrieb:
> malloc allokiert in dem Fall 128 C 'Bytes', die auf diesem System> dann 512 unsere üblichen 8 Bit Bytes entsprechen.
Ok, dass macht dann wieder Sinn.
Klaus schrieb:
>> for(i=0;dooo(),++i;);>> Was will uns dieser Beitrag sagen?!?
Dass diese Schleife ebenfalls 256mal durchlaufen wird und dabei
256mal die Funktion dooo() aufgerufen wird. Ist allerdings schon
beinahe IOCCC-verdächtig. ;-)
Bleifuss schrieb:
> Dann sollte sizeof(irgendein_int32_typ) aber auch 1 zurückgeben....
Tut es auch. Noch besser: Auf dem TMS320C3x und -C4x ist auch
sizeof(double) == 1
Jörg Wunsch schrieb:
> Klaus schrieb:>>>> for(i=0;dooo(),++i;);>>>> Was will uns dieser Beitrag sagen?!?>> Dass diese Schleife ebenfalls 256mal durchlaufen wird und dabei> 256mal die Funktion dooo() aufgerufen wird. Ist allerdings schon> beinahe IOCCC-verdächtig. ;-)
Aaaah. Gut entziffert!
Btw, for-Schleifen wo nicht alle 3 "Teile" vorhanden sind, sind meist
einfacher durch while oder do-while darstellbar. So als Faustregel.
Jörg Wunsch schrieb:
>>> for(i=0;dooo(),++i;);>>>> Was will uns dieser Beitrag sagen?!?>> Dass diese Schleife ebenfalls 256mal durchlaufen wird und dabei> 256mal die Funktion dooo() aufgerufen wird. Ist allerdings schon> beinahe IOCCC-verdächtig. ;-)
Jein.
dooo() wird 256 mal aufgerufen, weil es im Test steht.
"Die Schleife" im Sinne des Schleifenrumpfes (das Nichts vor
dem Semikolon) wird nur 255 mal durchlaufen.
Nur zur Sicherheit, um Mißverständnisse durch neue Unklarheiten
zu ersetzen...
Klaus Wachtler schrieb:
> Jein.>> dooo() wird 256 mal aufgerufen, weil es im Test steht.> "Die Schleife" im Sinne des Schleifenrumpfes (das Nichts vor> dem Semikolon) wird nur 255 mal durchlaufen.>> Nur zur Sicherheit, um Mißverständnisse durch neue Unklarheiten> zu ersetzen...
Ah, ja, wichtiger Hinweis! Dann kann man natürlich keine andere Schleife
benutzen um den "Effekt" zu benutzen.