while (1) Äquivalenz

Das eine läuft für immer, das andere nur bis der Stack voll ist.

mh schrieb:
> , das andere nur bis der Stack voll ist

;)

10:
goto 10

for(;;);

Keine Ahnung schrieb:
> while (1)
> äquivalent zu?
> void FunktionA (void)
> void FunktionB (void)
>
> void FunktionA()
> {
>   FunktionB();
> }
>
> void FunktionB()
> {
>   FunktionA();
> }

C++: vermutlich Ja.
C: vermutlich Nein.

Vorausgesetzt es gibt irgendwo ein main(){functionA();} ...

Warum der Weg über B und nicht gleich A rekursiv?

Sowas geht nur in LISP gut.

Oliver S. schrieb:
> Eins von beiden ist vermutlich falsch.

Wieso? Falls du es nicht wusstest

1

while(1){}

ist in c++ nicht erlaubt. Es geht also nur um die Rekursion ohne 
"forward progress"

mh schrieb:
> while(1){}
> ist in c++ nicht erlaubt.

Ja?
Wo kann man das nachlesen?

Der (endliche) Stack wird überlaufen.

Wenn eine Funktion aufgerufen wird, muss der Computer beim Verlassen der 
Funktion rauskriegen, von wo aus die Funktion aufgerufen wurde, damit er 
da weitermachen kann. Dafür wird er bei jedem Funktionsaufruf eine 
Rücksprungadresse auf dem Stack ("Stapel") ablegen. Wenn eine Funktion 
verlassen wird, wird diese Rücksprungadresse wieder entfernt.

Bei dir wird nie eine Funktion verlassen und daher die Rücksprungadresse 
auch nie entfernt. Folglich wächst der Stack stetig weiter, bis eben 
kein Speicher mehr da ist.

Du könntest das erreichen wie Ben sagt, indem du keine Funktionsaufrufe 
verwendest, sondern direkt zu den Funktionen springst. Soweit ich weiß 
müsstest du dann aber Assembler Instruktionen verwenden:

1

void FunktionA()

2

{

3

  __asm jmp FunktionB

4

}

5

6

void FunktionB()

7

{

8

  __asm jmp FunktionA

9

}

Du kannst ansonsten wie BumsFallera sagt, einfach keine Funktionen 
nutzen, sondern Label und dann das goto Schlüsselwort nutzen:

1

{

2

FunktionA:

3

  goto FunktionB;

4

FunktionB:

5

  goto FunktionA;

6

}

Arduino Fanboy D. schrieb:
> mh schrieb:
>> while(1){}
>> ist in c++ nicht erlaubt.
>
> Ja?
> Wo kann man das nachlesen?

http://eel.is/c++draft/intro.progress

1

3 During the execution of a thread of execution, each of the following is termed an execution step:

2

(3.1) termination of the thread of execution,

3

(3.2) performing an access through a volatile glvalue, or

4

(3.3) completion of a call to a library I/O function, a synchronization operation, or an atomic operation.

und

1

5 [ Note: Because of this and the preceding requirement regarding what threads of execution have to perform eventually, it follows that no thread of execution can execute forever without an execution step occurring. — end note ]

Du möchtest mir sagen, dass mein GCC 9.2 und auch alle gerade 
erreichbaren Vorgänger defekt sind, weil sie bei "while(1){}" das zu 
erwartende Verhalten (Endlosschleife), ohne jede Warnung, zeigen.

Ok ...

Arduino Fanboy D. schrieb:
> Du möchtest mir sagen, ...

Nein, möchte ich nicht. Aber der gcc könnte etwas anderes machen, wenn 
er will.

clang optimiert den Aufruf von foo in folgendem Beispiel weg.

1

void foo() {

2

  while(true) {}

3

}

4

5

int main() {

6

  foo();

7

  return 0;

8

}

Das Programm terminiert.
Dagegen bleibt die while-Schleife in:

1

int main() {

2

  while(true) {}

3

  return 0;

4

}

erhalten.

1

> void FunktionA()

2

> {

3

>   __asm jmp FunktionB

4

> }

5

6

> void FunktionB()

7

> {

8

>   __asm jmp FunktionA

9

> }

Das waere ja gemogelt. Aber evtl taete es ein:

1

void __attribute__ ((naked)) FunktionA (void)

2

void __attribute__ ((naked)) FunktionB (void)

3

4

void __attribute__ ((naked)) FunktionA()

5

{

6

  FunktionB();

7

}

8

9

void __attribute__ ((naked)) FunktionB()

10

{

11

  FunktionA();

12

}

Rolf M. schrieb:
> Das ist ja mal eine bescheuerte Regel.
Ich habe dann mal ein paar Fragen:
- Warum ist die Regel bescheuert?
- Glaubst du, das wurde in den Standard geschrieben, um Leute zu ärgern?
- Kannst du ein gutes Beispiel geben, wo die Regel wirklich stört?

Rolf M. schrieb:
>> - Warum ist die Regel bescheuert?
>
> Weil ich keinen Sinn darin erkennen kann.
>
>> - Glaubst du, das wurde in den Standard geschrieben, um Leute zu ärgern?
>
> Nein, aber ich weiß auch nicht, welchem Zweck diese Regel dienen könnte.

Weil du keinen Sinn in der Regel erkennen kannst, ist die Regel 
bescheuert? Was soll man dagegen sagen? Ich versuche es mal direkt:
Ich gehe erstmal davon aus, dass es einen sehr guten Grund gibt für 
diese Regel. Das ist im Allgemeinen ein gutes Vorgehen, wenn man keine 
Ahnung hat. Ist nicht böse gemeint, aber du hast bewiesen, dass du von 
diesem speziellen Thema keine Ahnung hast (du kanntest die Regel 
nicht, du hast kein Argument außer "dann muss ich Dinge anders lösen").

Rolf M. schrieb:
> Und jetzt könntest du mir im Gegenzug ein Beispiel geben, wo diese Regel
> wirklich hilft.

Kann ich nicht, ich habe noch nie eine Endlosschleife gebraucht, aber 
ich freue mich immer, wenn der Compiler optimiert. Im Standard selbst 
steht z.B.

1

[ Note: This is intended to allow compiler transformations such as removal of empty loops, even when termination cannot be proven. — end note ]

also gibt es vermutlich Leute, denen diese Optimierung wichtig ist. Dann 
kommt recht häufig "forward progress guarantee" und "lock-free 
execution" vor. Also wird es vermutlich Leute geben, die diese Garantie 
brauchen. Das ist gut genug für mich.

Zu deinen Beispielen:
-Dein Idle-Thread ist mir etwas suspekt. Es gibt keine Möglichkeit mit 
diesem Thread zu interagieren (pausieren, stoppen)? Ist das ein 
regulärer Thread oder genießt er eine Sonderbehandlung? Was passiert 
wenn die Rechenleistung gebraucht wird?
-Der Fehlerhandler könnte auch einfach das "Programm" terminieren.







Oliver S. schrieb:
> Aber daraus abzuleiten, daß while(1){} in C++ nicht erlaubt sein, halte
> ich für sehr gewagt.

Ich gebe zu, die Formulierung "verboten" ist etwas zu stark. Aber viel 
Platz für Interpretation lässt der von mir zitierte Teil nicht:

1

5 [ Note: Because of this and the preceding requirement regarding what threads of execution have to perform eventually, it follows that no thread of execution can execute forever without an execution step occurring. — end note ]

Ich habe den "Was darf das Programm" Teil zitiert. Du hast den "Was darf 
der Compiler" Teil zitiert.

Yalu X. schrieb:
> Das scheint nicht dem C++20-Draft zu entstammen, sondern wohl weiter in
> die Zukunft zu blicken. Vielleicht werde diese Dinge ja noch geändert.

Das müsste der 20er Draft Stand 2020-04-09 sein. Müsste ähnlich auch 
schon in C++11 gewesen sein.

Yalu X. schrieb:
> Wobei es diesen Unfug in C ja schon seit C11 gibt, allerdings mit einem
> entscheidenden Unterschied: Schleifen, deren Abbruchbedingung ein
> konstanter Ausdruck ist (wo der Compiler also leicht entscheiden kann,
> ob die Schleife terminiert oder nicht), werden ganz klassisch
> gehandhabt.

Ja in C gibt es eine explizite Ausnahme für Schleifen mit konstantem 
Ausdruck als Abbruchbedingung. Ansonsten sind auch da Endlosschleifen 
mit nicht konstanter Bedingung Freiwild.

Yalu X. schrieb:
> Das scheint nicht dem C++20-Draft zu entstammen, sondern wohl weiter in
> die Zukunft zu blicken.

Ich wills nicht hoffen.

Bisher ist mit AVR gcc 9.2 und -std=gnu++2a -Os eine Endlosschleife noch 
eine Endlosschleife.

(werde es im Auge behalten)

Rekursion ist doch was feines...
endlosschleifen auch.. warum also nicht..
wie wär's hiermit:

1

int ack(int a, int b)

2

{

3

   int c;

4

   if (a==0) c = b+1;

5

   else if (b==0) c = ack(a-1,1);

6

   else c = ack(a-1, ack(a, b-1));

7

   return c;

8

}

und nu nurmal so aus Spass.. was einfaches.. ack(4,3) zB..
ich denke das darf man dann auch als Endlossschleife bezeichen :D

Mahlzeit

'sid

sid schrieb:
> warum also nicht..

sid schrieb:
> was einfaches.. ack(4,3) zB..

Weil es undefined behaviour ist (signed integer overflow). Alternativ 
kannst du mir die Bitbreite des integer Datentyps angeben, mit dem es 
funktioniert.

Yalu X. schrieb:
> while(1);
> for(;;);
> Nur mit Clang/LLVM geeht das nicht

Das ist aber eine sehr unangenehme Überraschung.

Aber den von Dir geschilderten Segmentation fault kann wohl niemand mir 
gesunder Logik für gewollt halten, oder?

Rolf M. schrieb:
> Du hast aber offenbar genauso wenig Ahnung, weil du auch nicht weißt,
> wozu diese Regel dienen soll. Du freust dich aber trotzdem darüber, weil
> du denkst, dass sie ja irgendwie gut sein muss.

Ich habe nie gesagt, dass ich besonders viel Ahnung habe, oder sogar ein 
Experte bin. Ich kannte die Regel aber immerhin. Und warum sollte ich 
mich nicht darüber freuen wenn der Standard Wert darauf legt, dass 
Optimierungen möglich sind? Was soll ich gegen diese Regel haben, wenn 
ich in ~15 Jahren c++ noch keine Endlosschleife benötigt habe?

Rolf M. schrieb:
> Für mich eben nicht.
Du benötigst für alles was im Standard steht eine Begründung, die deinen 
Ansprüchen genügt? Viel Spass beim warten.

Rolf M. schrieb:
> Der darf niemals pausiert oder gestoppt werden. Das ist ja gerade der
> Sinn des Idle-Threads.
Mir ist klar, was ein Idle-Thread ist. Ich sehe nur nicht so ganz wie 
dieses Konzept in c++ funktionieren soll, ohne den Standard zu verlassen 
(zusätzlich zu Endlosschleifen).

Rolf M. schrieb:
> Auf einem Rechner mit Betriebssystem ja. Aber was verstehst du auf einem
> µC unter "das Programm terminieren"? Und was denkst du, was der nach dem
> Terminieren macht?
In eine Endlosschleife laufen. Der Compiler/stdlib, darf sie benutzen.

mh schrieb:
> wenn
> ich in ~15 Jahren c++ noch keine Endlosschleife benötigt habe?

Hmmm...

Wenn mich nicht alles täuscht, dann kann man schon soweit gehen, und 
sagen, dass jedes Programm, jeder Prozess, jeder Thread, eine 
Endlosschleife benötigt.
Egal wie fett der Prozessor ist, egal welches OS.
Von Win über Linux, und auch FreeRtos.

OK, das "jeder" ist evtl. ganz leicht übertrieben.
Ein paar Sonderfälle kann man da evtl. abziehen.
Aber das bestätigt nur die Regel.

Ob es immer die Kurzform
> while(1);
> for(;;);
sein muss, ist eine andere Frage.

Aber Endlosschleifen, die finden sich wie Sand am Meer.
Oftmals, ohne jede Alternative.

Ja, nee....


Der Kollege sagte:
> wenn
> ich in ~15 Jahren c++ noch keine Endlosschleife benötigt habe?
DAS habe ich in Zweifel gezogen.

Yalu X. schrieb:
> Verboten sind nur solche, die
> keinen Effekt haben
Dass mir DAS nicht schmeckt, ist ein ganz anderes paar Schuhe.

Denn ich habe einige Programme im Feld, welche genau diese leere 
Schleife verwenden.
Manche, wo es als halt() eingesetzt wird, aus dem nur ein Reset die 
Erlösung bringt, und einige, welche eigentlich nur im Interrupt laufen, 
und die Schleife dazu dient, ungenutzte Zeit zu vertrödeln.

Yalu X. schrieb:
> for(;;) {
>     volatile char x;
>     (void)x;
>   }
Schmeckt mir auch nicht sonderlich gut.

Yalu X. schrieb:
> ich heute etwas wirklich Interessantes dazugelernt habe,
Ich auch.
Mal schauen, wann es mir erstmalig auf die Füße fällt.

mh schrieb:
> Weil es undefined behaviour ist (signed integer overflow). Alternativ
> kannst du mir die Bitbreite des integer Datentyps angeben, mit dem es
> funktioniert.

'tschuldigung, ich habe die Ackermannfunktion als bekannt vorausgesetzt 
und deswegen den Sarkasmus-tag nicht benutzt.

bitbreite.. weiss nicht,dürfte so um  2^(2^65536) sein oder so;
ich ging also davon aus, dass der overflow das geringste aller Probleme 
sein dürfte,
da sie eh erst Wochen nach dem Wärmetod des Universums terminiert ;)
und sind wir ehrlich dann ist die korrekte Antwort darauf auch egal :D

Mahlzeit

'sid

Arduino Fanboy D. schrieb:
> Denn ich habe einige Programme im Feld, welche genau diese leere
> Schleife verwenden.
> Manche, wo es als halt() eingesetzt wird, aus dem nur ein Reset die
> Erlösung bringt, und einige, welche eigentlich nur im Interrupt laufen,
> und die Schleife dazu dient, ungenutzte Zeit zu vertrödeln.

ja..
"Arduino Fanboy" gibt auch Auskunft darüber wo diese Programme dan 
eingesetzt werden nehm ich an ;)

klar braucht man in microControllern schonmal ein "Ende"
Das Problem liegt aber daran dass dein Code generell IMMER in einer 
Endlosschleife läuft (void loop()) und du dessen Ausführung blockieren 
willst, es aber aus besagter loop funktion kein return gibt soweit ich 
weiss.

Ausserhalb von µCs allerdings sind solche Schleifen eher unerwünscht
(vorsichtig formuliert) und man will sie um jeden Preis vermeiden, damit 
das Programm auch eine Rückgabe erzeugt mindestens eine Fehlermeldung.

Also Äpfel und Birnen, ihr redet klar aneinander vorbei...

'sid

Arduino Fanboy D. schrieb:
> mh schrieb:
>> wenn
>> ich in ~15 Jahren c++ noch keine Endlosschleife benötigt habe?
>
> Hmmm...
>
> Wenn mich nicht alles täuscht, dann kann man schon soweit gehen, und
> sagen, dass jedes Programm, jeder Prozess, jeder Thread, eine
> Endlosschleife benötigt.

Und "jedes Programm, jeder Prozess, jeder Thread" benötigt vermutlich 
einen Kontextwechsel. Jetzt rate mal wieviele ich davon standardkonform 
in C++ geschrieben habe?

S. R. schrieb:
> mh schrieb:
>> In eine Endlosschleife laufen.
>
> Womit wir wieder beim Problem wären...
Hättest du den zweiten Satz gelsen...
mh schrieb:
> In eine Endlosschleife laufen. Der Compiler/stdlib, darf sie benutzen.

Rolf M. schrieb:
> Nicht für alles, aber ich befinde umgekehrt auch nicht alles automatisch
> für gut, nur weil's halt da drin steht.

Aber von mir verlangst du, dass ich die genauen Gründe für diese Regel 
kenne. Sonst darf ich mich nicht freuen, dass der Standard Regeln 
einführt, die den Compilern bessere Möglichkeiten zum Optimieren gibt.

sid schrieb:
> 'tschuldigung, ich habe die Ackermannfunktion als bekannt vorausgesetzt
> und deswegen den Sarkasmus-tag nicht benutzt.
Ich kenne die Ackermannfunktion, kann in dem Post trotzdem keinen 
Sarkasmus erkennen.

sid schrieb:
> da sie eh erst Wochen nach dem Wärmetod des Universums terminiert ;)
> und sind wir ehrlich dann ist die korrekte Antwort darauf auch egal :D
Das kommt ganz aufs System an. Ich bin in weniger als 1 Sekunde in den 
a=0 b=Overflow gerannt für ack(4,3).

Yalu X. schrieb:
> aber mit
> höheren Optimierungsstufen sieht die Ausgabe so aus:
>
> begin
> begin
> Segmentation fault (core dumped)

Wow, gerade auch mit clang 8.0.0-3~ubuntu16.04.1 versucht, mit Optionen 
"clang++-8 -O2 -std=c++14 -Wall -Wextra -pedantic". Selbes Ergebnis, und 
vor allem, keine Warnung!!! Mit clang 3.8 lief es noch. Also, 
normalerweise verstehe ich es ja, wenn wegen UB etwas anders/nicht 
läuft, normalerweise gibt es zumindest nen vernünftigen Grund dafür. 
Aber das hier, das geht gar ja wohl nicht! Ohne die geringste Warnung, 
trotz maximaler Warnhöhe, ein Programm, wegen einem Teil, wo niemand 
bestreiten würde, was es tun sollte, derart zu Zerreissen, also da hört 
mein Verständnis für sowas dann doch mal langsam auf. Weiss jemand, 
wer dafür verantwortlich ist?

mh schrieb:
>> da sie eh erst Wochen nach dem Wärmetod des Universums terminiert ;)
>> und sind wir ehrlich dann ist die korrekte Antwort darauf auch egal :D
> Das kommt ganz aufs System an. Ich bin in weniger als 1 Sekunde in den
> a=0 b=Overflow gerannt für ack(4,3).

ne kommt nicht auf das System an,
Du hast nicht ausreichend bits in deinem Computer um es auch nur zu 
versuchen..
es benötigt weit mehr bits als Protonen im bekannten Universum
ganz zu schweigen dass der Aufrufstack dir selbst irgendwann in den 
Nacken schlägt.

mh schrieb:
> Ich kenne die Ackermannfunktion, kann in dem Post trotzdem keinen
> Sarkasmus erkennen.
scheinbar kennst Du sie nicht.
Denn dann würdest Du es garnicht erst probieren laufen zu lassen..
selbstredend rennst Du zuerst in nen Overflow; völlig egal wie
Also ist die Frage nach der bitzahl schon völlig Hirnlos in diesem 
Zusammenhang.
Und der unumstössliche Beweis, dass Du sie nicht kennst.
(oder ihre grauenhafte Art jmd in die Falle tappen zu lassen)
da die Funktionsparameter kontinuierlich fallend aussehen
und nur der Rückgabewert in Einzelschritten incrementiert,
scheint sie harmlos, tritt einem aber gehörigst in den Allerwertesten 
bei nur kleinen Aufrufparametern (4,3) scheint ja überschaubar.
Den Sarkasmus darin erkennt man in der Tat nur wenn man das vorher 
weiss.

hättest Du sie erkannt hätte Dir schon
https://de.wikipedia.org/wiki/Ackermannfunktion#Genauere_Betrachtung

geholfen das gehässige an (4,3) zu sehen
Zitat:
----
Wir betrachten nun einen komplexeren Fall, nämlich a ( 4 , 3 ) , den 
ersten Funktionswert, der so groß ist, dass er praktisch nicht dezimal
aufgeschrieben werden kann.
...
Wenn wir an dieser Stelle mehrere logische Schritte überspringen, 
könnten wir a ( 2 , 5 )  zu 13 auswerten und dann versuchen,
a ( 3 , 13 )
auszuwerten – das ist 65533. Doch schon der nächste Funktionsaufruf 
liefert mit a ( 3 , 65533 )  eine Zahl, die weit über die geschätzte 
Anzahl
der Atome im Universum hinausgeht. Diese Zahl m  wird schließlich in die 
Berechnung
a ( 3 , m )  eingesetzt, die irgendwann zu einem Ausdruck
der Form a ( 2 , a ( 2 , a ( 2 , … , a ( 2 , 0 ) … ) ) )  ausgeschrieben 
würde, die aber mit unseren Mitteln nicht mehr aufgeschrieben werden 
kann.
------------

Wie gesagt, ich habe zu unrecht erwartet dass man sie erkennt;
mein Fehler..
aber dass Du jetzt so tust Du hättest sie erkannt und im selben Atemzug 
sagst Du hättest es dennoch probiert (und auch noch ein Ergebniss 
erwartet)
dann zeigt das klar, dass Du lügst (oder es dir an Auffassunggabe und 
Zurechnungsfähigkeit mangelt)

Sarkasmus nicht erkannt?

sid schrieb:
> Rekursion ist doch was feines...
> ....
> und nu nurmal so aus Spass.. was einfaches.. ack(4,3) zB..
> ich denke _das darf man dann auch als Endlossschleife bezeichen_ :D

einfach..(HUST) "darf man als Endlosschleife bezeichnen" (ZAUNPFAHLWINK)

Ja ggf nicht klar genug, deswegen meine obige Entschuldigung;
aber bitte, tu jetzt nicht so als läge es an einer fehlenden Angabe der 
bitbreite, denn dir fehlt Kapazität auch nur die Anzahl der bits 
auszuschreiben und tu nicht so als sei die Berechnung eine Frage der 
Rechenkapazität;
denn auch nur der Gedanke Du seist in der Lage ist völlig absurd.
Lass Deinen Computer mal bis 2^512 hochzählen (in Einzelschritten)
(stop die Zeit!) und dann überleg mal was 2^65536 ungefähr dauern 
könnte.
und nun kommen wir zurück auf 2^(2^65536) ... Na?? merkste was?
2^65536 sind etwa 19729 dezimalziffern und das ist nur der exponent.

'sid

sid schrieb:
> ne kommt nicht auf das System an,
> Du hast nicht ausreichend bits in deinem Computer um es auch nur zu
> versuchen..
Natürlich kommt es aufs System an, wann man in den Overflow läuft.

sid schrieb:
> ganz zu schweigen dass der Aufrufstack dir selbst irgendwann in den
> Nacken schlägt.
Der Stack hat noch ordentlich Luft nach oben.

sid schrieb:
> scheinbar kennst Du sie nicht.
> Denn dann würdest Du es garnicht erst probieren laufen zu lassen..

Ich darf also nicht testen, ob zuerst nen stack overflow oder signed 
integer overflow eintritt, und wann genau?

sid schrieb:
> Sarkasmus nicht erkannt?
>
> sid schrieb:
>> Rekursion ist doch was feines...
>> ....
>> und nu nurmal so aus Spass.. was einfaches.. ack(4,3) zB..
>> ich denke das darf man dann auch als Endlossschleife bezeichen :D
>
> einfach..(HUST) "darf man als Endlosschleife bezeichnen" (ZAUNPFAHLWINK)

Auch wenn du das Zitat abänderst ist das kein Sarkasmus, bestenfalls 
Ironie.

Für den Fall, dass du irgendwann mit deinen Unterstellungen fertig bist 
und zu einer Diskussion bereit bist, fasse ich meinen Standpunkt nochmal 
zusammen, den ich mit dem Beitrag
mh schrieb:
> sid schrieb:
>> warum also nicht..
>
> sid schrieb:
>> was einfaches.. ack(4,3) zB..
>
> Weil es undefined behaviour ist (signed integer overflow). Alternativ
> kannst du mir die Bitbreite des integer Datentyps angeben, mit dem es
> funktioniert.
darstellen wollte. Deine Funktion, mit den Werten a=4, b=3 aufgerufen, 
produziert einen signed integer overflow und ist nach Standard damit 
undefined behaviour. Wenn der Compiler das mitbekommt kann er machen was 
er will, z.B. nach 42 Sekunden (lange vor dem Wärmetod des Universums) 
den Wert 7353 zurückgeben. Die Bitbreite ist also der entscheidende 
Punkt. Und falls du es noch nicht gemerkt hast, deine Antwort
sid schrieb:
> bitbreite.. weiss nicht,dürfte so um  2^(2^65536) sein oder so;
ist falsch (mehrere Größenordnungen).

mh schrieb:
> Auch wenn du das Zitat abänderst ist das kein Sarkasmus, bestenfalls
> Ironie.
Ohweh, Mathe nicht, Sprache nicht... naja dann; wie isset mit Religion?
wiki schreibt:
>Sarkasmus kann durch direkte Aussage des Gemeinten oder mittels Ironie 
ausgedrückt werden.
Aber lassen wir das, nicht dass Du da in die nächste Selbstgeisselung 
rennst.

mh schrieb:
> Ich darf also nicht testen, ob zuerst nen stack overflow oder signed
> integer overflow eintritt, und wann genau?

ne, brauchste ja nicht.. weiss man ja wenn man die Funktion kennt..
hab ich dir ja sogar zitiert..

sobald die Funktion sich selbst mit (3,65533) aufruft
rennst Du zwangsläufig in einen integer overflow.. EGAL BEI WELCHER 
BITBREITE!
und der stack dürfte da noch an zehn Fingern abzuzählen sein.
'würde' das durchlaufen (was es nicht kann...) würde Dir im 
darauffolgenden Schritt der stack überlaufen.. genauso zwangsläufig wie 
der integer overflow auftritt,
weil das Ergebniss dessen jene besagten 19729 Ziffern sind
(2^65536) und genausooft
würde die Funktion sich selbst verschachtelt aufrufen wollen ('tschüss 
stack!');
um dann das (ab sofort nurnoch fiktive) Ergebniss (in der Nähe von 
2^2^65536) auszuspucken
besagte Wochen nach dem Wärmetod des Universums, wenn der Stack dann 
wieder abzählbar ist.

Wie gesagt, wenn man die Funktion kennt, weiss man das;
man weiss auch dass der integer overflow IMMER exakt einen (fiktiven) 
Schritt auf selber stackebene vor dem unausweichlichen Stack Overflow 
kommt.

Wie gesagt, Du bestätigst nur nochmals, dass Du die Funktion eben 
nicht kennst,
mindestens aber Dir ihrer Gemeinheit nicht im Klaren bist;
maximal glaub ich noch, dass Du mal von ihr gehört hast.
Das ist ansich nichts schlimmes.. (muss man nicht wissen mMn)
Aber ernsthaft, langsam wird es albern mit deinem sich rausreden wollen,
Denn dann allerdings muss ich dir wirklich Ignoranz oder Dummeheit 
unterstellen,
anders kann ich mir das nichtmehr erklären wieso man es überhaupt 
versucht unter der Prämisse die Funktion "zu kennen".
Ich fürchte fast Du hast nichteinmal eine Ahnung wie gross die Zahlen 
sind,
von denen Du da glaubst sie "berechnen" zu können,
was Dich dann allerdings in wirklich schlechtes Licht tauchen würde.
Sone ungefähre Ahnung von Grössenordnung sollte man schon haben
10^80 geschätzte Atome im Universum verglichen mit 2^65536 als EXPONENT
macht einem recht einleuchtend klar (hoffentlich) dass jeder Versuch 
zwangläufig vollends NUTZLOS ist.


S. R. schrieb:
> Das ist falsch, weil es sich eben nicht wie eine Endlosschleife verhält,
> auch nicht für reale Zeitverhältnisse.

da es keine realen Zeitverhältnisse gibt nach dem Wärmetod des 
Universums ist der Einwand eher zu vernachlässigen.
Die Funktion KANN sich real nicht "korrekt" verhalten mit den 
Aufrufparametern (4,3),
eben WEIL sie die Ackermannfunktion ist und egal welcher Computer sich 
eben mit begrenzten Ressourcen zufriedengeben muss.
Mit kleineren Aufrufparametern kann sie sich nicht wie eine 
"Endlossschleife" verhalten, weil man eben nur ein Ergebniss 
zurückbekommt,
und zwar in sehr realen und überschaubaren "Zeitverhältnissen"

Aber jaja.. ich hab verstanden,
ich bin der Einzige der das lustig fand zu dieser -da müsst ihr aber 
zustimmen- ziemlich bekloppten Fragestellung.

'sid

sid schrieb:
> Sarkasmus nicht erkannt?

sid schrieb:
> Aber jaja.. ich hab verstanden,
> ich bin der Einzige der das lustig fand

Was soll man dazu sagen?

sid schrieb:
> Sarkasmus kann durch direkte Aussage des Gemeinten oder mittels Ironie
> ausgedrückt werden.

Falls du es noch nicht weißt, nicht immer ist das "direkte Aussagen des 
Gemeinten" Sarkasmus. Es gibt noch andere Bedingungen ;-)

Rolf M. schrieb:
>> - Warum ist die Regel bescheuert?
>
> Weil ich keinen Sinn darin erkennen kann.

Ah ja. Das ist der Standpunkt "was ICH nicht weiß, das gibt es auch 
nicht!" (oder "..darf es nicht geben!")

Ich sehe das wieder mal etwas anders:

Ein while(1) ist eigentlich eine Vergewaltigung einer bedingten 
Schleife, genauso wie es ein for(;;) ist. Bedingte Schleifen sind dafür 
da, eben BEDINGT zu sein und nicht zur unbedingten Schleife verhunzt zu 
werden.

Also ist so etwas einfach nur ein schlechter Programmierstil und ich 
habe kein Problem damit, wenn eine Regel so etwas stigmatisiert.

Und wenn man eine tatsächliche unbedingte Schleife haben will, dann 
setzt man ein Label und benutzt goto. Das wird ja wohl hoffentlich 
nicht mal vom GCC hinweg optimiert. Und Label + goto ergeben die 
klassische unbedingte Schleife.

W.S.

W.S. schrieb:
> Und Label + goto ergeben die
> klassische unbedingte Schleife.

Womit man dann erst am Ende weiß das es eine Endlosschleife ist und auch 
das nur vielleicht. Weil wer goto nimmt springt dann auch per goto zum 
erroerhandler. Proggst du in Assembler? Da macht das evtl. Sinn.

Der Compiler macht aus while(1) das gleiche wie aus for... und goto.

Der goto man verliert aber die Programmstruktur und darf sich zum Ende 
durchwühlen wenn er daraus ne Funktion machen will.

Rolf M. schrieb:
> Bei while(1) gebe ich dir recht, da man als "Bedingung" etwas einträgt,
> das immer wahr ist und somit das Konzept der bedingten Wiederholung
> eigentlich ad absurdum geführt wird.

Warum? Die Bedingung ist halt immer wahr. Wenn 21. Juni dann 
Sommersonnenwende ist auch immer wahr. Nur halt nicht jeden Tag.

Man macht das wg. konsistenter Programmstrukturen und ein goto ist da so 
fehl am Platze wie while(4 != Pi()) was ja ne "echte" Bedingung mit dem 
gleichen Ergebnis wäre.

Rolf M. schrieb:
> Einfach weil es eine präzisere
> und direktere Beschreibung meiner Absicht ist
Naja..
Man kann "Absicht" auf verschiedene Art ausdrücken.


Toby P. schrieb:
> Der goto man verliert aber die Programmstruktur und darf sich zum Ende
> durchwühlen wenn er daraus ne Funktion machen will.

Bin mittlerweile voll auf Goto!

Klarer:
Listig eingesetzte Goto können die Absicht auch verdeutlichen!
Und gleichzeitig helfen die Komplexität zu verbergen.

Im Anhang mal ein Beispiel, wie das(manchmal) in meiner kleinen 
(hauptsächlich AVR) Arduino Welt aussieht.

OK, das ist kein SpeicherSparWunder, aber es drückt die "Absicht" recht 
klar aus, auch wenn das goto schön versteckt ist, und einige 
Endlosschleifen da rum dümpeln


---
Goto hat seinen schlechten Ruf aus vergangen Zeiten, und mit anderen 
Sprachen, als C oder C++, erworben.

Sicherlich kann man mit Goto auch derbe Mist bauen!
Aber das gilt wohl auch für alle anderen Sprachmittel.

PS:
Die Library habe ich nicht dazu gepackt.
1. interessiert vermutlich sowieso keinen hier
2. ist (noch) nicht gefegt und poliert

Meine Endlosschleife auf dem C64 (Commodore Basic V2):

1

10 for i=0 to 9e9

2

...

3

90 next

Der begrenzten Genauigkeit wegen, kann der Endwert nie erreicht 
werden.
Vorteil: Die literale Sprungadresse liegt wegen der for-Schleife auf
dem for-next Stack und muss nicht aufwendig gesucht werden.

Toby P. schrieb:
> Der Compiler macht aus while(1) das gleiche wie aus for... und goto.

Hast du hier nichts gelesen? Die ganze Diskussion ging darum, daß der 
GCC sowas wie while(1) einfach wegoptimiert. Er fährt also dem 
Programmierer einfach so über's Maul (!!!) - weil eben mal wieder irgend 
wer von den Compilerbauern den Sinn von etwas nicht hat einsehen wollen 
und gemäß der Direktive "was ich nicht einsehe, das darf nicht sein" 
sowas offenbar zum Wegoptimieren freigegeben hat.

OK, ich selber benutze den GCC aus derartigen Gründen nicht, aber es 
erstaunt mich immer wieder, mit was für eigentümlichen Hakeleien die 
GCC-Benutzer sich herumschlagen müssen.

Was also tun, wenn sowas wie while(1) nicht geht? Mir fällt (siehe oben) 
da nur das dedizierte GOTO marke ein, in der Hoffnung, daß die 
Compilerbauer nicht derart frech sind, dieses ebenfalls wegzuoptimieren.

Muß man beim GCC mit der Brechstange programmieren?

Wie schonmal gesagt: von einem Compiler erwarte ich, daß er das, was ich 
hingeschrieben habe, richtig und optimal in Maschinencode übersetzt - 
aber er hat nicht auf eigene Faust irgendwas zu unterschlagen - bloß 
weil irgendwer das nicht einsehen wollte.

W.S.

W.S. schrieb:
> OK, ich selber benutze den GCC aus derartigen Gründen nicht, aber es
> erstaunt mich immer wieder, mit was für eigentümlichen Hakeleien die
> GCC-Benutzer sich herumschlagen müssen.

Der gcc macht diese Optimierung gerade NICHT.

Mal davon abgesehen, dass der Nutzer einen Fehler gemacht hat, wenn er 
den gcc zum Compilieren von C++ benutzt, dafür ist der g++ gedacht.

Rolf M. schrieb:
> GCC ist die GNU Compiler Collection.
Dann ist es aber nicht "der/den GCC" ;-)

Rolf M. schrieb:
> Zu der gehört das C++-Frontend g++ und das allgemeine Frontend für alle 
unterstützten Sprachen gcc.
Das ist mir bekannt. Mir ist aber auch bekannt, dass das unter anderem 
beim Linken einige Probleme machen kann (einfachster Fall stdlib von 
Hand dazulinken). Es gibt nen Grund warum es den g++ gibt und der gcc 
selbst

1

When you compile C++ programs, you should invoke GCC as g++ instead.

sagt.

Christopher J. schrieb:
> Der "Keil" nutzt in seinen aktuellen Versionen

Der geht mich nix an. Meine Lizenz ist schon ein paar Jährchen alt - und 
sie reicht aus für alles, was bei mir anfällt.

W.S.