Code::Blocks Program schließt sich bei Rechenoperationen

Unterfliege

@Zentralheizung ich würde eher von system("pause"); abraten.
Dies schafft nur einen unnötigen Systemaufruf und Plattformabhängigkeit.
Nutze lieber z.B. std::cin.get();. Damit wartet dein Programm darauf, dass <Enter> gedrückt wird.

It0101

@Unterfliege sagte in Code::Blocks Program schließt sich bei Rechenoperationen:

@Zentralheizung ich würde eher von system("pause"); abraten.
Dies schafft nur einen unnötigen Systemaufruf und Plattformabhängigkeit.
Nutze lieber z.B. std::cin.get();. Damit wartet dein Programm darauf, dass <Enter> gedrückt wird.

In der Praxis braucht das "system("pause")" eh kein Mensch, weil man solche Konsolentools sowieso aus einer Shell startet.
Für einen Frischling ist auch die Platzformabhängigkeit irrelevant

Unterfliege

@It0101 man kann aber vllt. lieber von Anfang an die bessere Alternative nutzen, wenn sie genauso einfach zu benutzen ist.
Es ist ja auch nicht nur dir Plattformabhängigkeit. Es ist dazu langsamer sowie umständlicher und schlicht und ergreifend schlechter Stil.
Klar, das mag zu Beginn egal sein, aber wenn man die Wahl hat, sollte man meiner Meinung nach lieber darauf verzichten.

RBS2

@Unterfliege sagte in Code::Blocks Program schließt sich bei Rechenoperationen:

@Zentralheizung ich würde eher von system("pause"); abraten.
Dies schafft nur einen unnötigen Systemaufruf und Plattformabhängigkeit.
Nutze lieber z.B. std::cin.get();. Damit wartet dein Programm darauf, dass <Enter> gedrückt wird.

Wenn alles egal ist, auch der Stromverbrauch, dann mach:

for(;;);

Das geht immer und überall.

Th69

Laut einer der Antworten in Why does my Codeblock only display output for less than second..? gibt es eine Option dafür in den Projekteinstellungen: "pause when execution ends".

DirkB

@Th69 das hilft aber nur, wenn man das Programm aus der IDE heraus startet.

Beim Doppelclick auf die .exe im Explorer hilft das auch nicht.

wob

@RBS2 sagte in Code::Blocks Program schließt sich bei Rechenoperationen:

Wenn alles egal ist, auch der Stromverbrauch, dann mach:
for(;;);
Das geht immer und überall.

Äh, nein, das geht nicht immer!

Beweis:

#include <iostream>

int foo(bool b) {
    if (b) return 42;
    for(;;);
    return 7;
}

int main(int argc, char **) {
    bool b = argc > 1;
    std::cout << std::boolalpha << b << '\n';
    return foo(b);
}

Kompiliere mal mit clang++-7 -O3. Und starte es mit einem Parameter und ohne Parameter. Es wird immer 42 zurückgegeben, die Endlosschleife wird nie ausgeführt. Der Compiler darf annehmen, dass Schleifen abbrechen oder stattdessen zumindest IO-Operationen durchführen (oder irgendwas mit Synchronisation/Locks tun)) - oder irgendwie so ähnlich, weiß gerade nicht, wo genau das im Standard steht. Deswegen funktioniert deine Endlosschleife nicht unbedingt.

RBS2

@wob sagte in Code::Blocks Program schließt sich bei Rechenoperationen:

Kompiliere mal mit clang++-7 -O3. Und starte es mit einem Parameter und ohne Parameter. Es wird immer 42 zurückgegeben, die Endlosschleife wird nie ausgeführt. Der Compiler darf annehmen, dass Schleifen abbrechen oder stattdessen zumindest IO-Operationen durchführen (oder irgendwas mit Synchronisation/Locks tun)) - oder irgendwie so ähnlich, weiß gerade nicht, wo genau das im Standard steht. Deswegen funktioniert deine Endlosschleife nicht unbedingt.

Schon seltsam. Ob er die Endlosschleife auch am Ende der main() ignoriert?

BTW, meine IDE (CLion 2018.1) sagt zu:

int foo(bool b) {
    if (b) return 42;
    for(;;);
    return 7;
}

Zeile 3: Endless loop.
Und Zeile 4 ist ausgegraut (heißt so viel wie 'Code wird nie ausgeführt')

wob

@RBS2
Siehe das hier aus n4713:

6.8.2.2 Forward progress [intro.progress]
1 The implementation may assume that any thread will eventually do one of the following:
(1.1) — terminate,
(1.2) — make a call to a library I/O function,
(1.3) — perform an access through a volatile glvalue, or
(1.4) — perform a synchronization operation or an atomic operation
[ Note: This is intended to allow compiler transformations such as removal of empty loops, even when
termination cannot be proven. — end note ]

Die Endlosschleife macht das nicht. Sollte also undefined behaviour sein.

Und beim Beispiel:

Und Zeile 4 ist ausgegraut (heißt so viel wie 'Code wird nie ausgeführt')
Zeile 3: Endless loop.
Da die Funktion irgendwann eines der oben genannten Dinge tun muss, kann man sicher sein, dass man nie in die endlose Scheife eintritt
Daher muss b true sein
Daher darf die Funktion auf "return 42" optimiert werden

RBS2

@wob sagte in Code::Blocks Program schließt sich bei Rechenoperationen:

Daher muss b true sein
Daher darf die Funktion auf "return 42" optimiert werden

Das glaube ich nicht. In der Realität kann b durchaus false sein.

Btw, Kapitel 6.8.2 handelt von 'Multi-threaded executions and data races', also um konkurrierenden Zugriff von mindestens zwei Threads auf die gleiche Variable oder Resource. Aber darum geht es hier doch gar nicht.