Code::Blocks Program schließt sich bei Rechenoperationen

[Zentralheizung]

Hallo,
ich arbeite mit dem Offline Editor Code::Blocks.Wenn ich einen Code fertiggestellt habe und gespeichert habe,taucht im Speicherort des Programms eine .exe auf.Leider ist es so,das wenn ich die exe aufrufe und z.B Bei einem Mini Taschenrechner von mir einen Wert eingeben habe passiert folgendes: Nachdem das Program anfängt zu rechnen,schließt es sich.Was kann ich dagegen tun?
MfG

[It0101]

Du wirst schon etwas präziser werden müssen:

Wenn du den Code gespeichert hast, passiert erstmal gar nichts. Das Speichern von Code in Dateien löst erstmal von allein gar nichts aus, außer Schreiboperationen auf der Festplatte.

Wo taucht die Exe auf?
Wie startest du die Exe?
Welches Programm stürzt ab? Codeblocks oder deine Exe?

[Ein ehemaliger Benutzer]

GUI? Qt? GTK+? wxWidgets?

[Zentralheizung]

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

Wo taucht die Exe auf?
Wie startest du die Exe?
Welches Programm stürzt ab? Codeblocks oder deine Exe?

Die exe taucht in dem Ordnern auf wo sich auch die anderen Dateien des Projekts befinden.

Ich starte die exe mit Doppelklick.

Die exe stürzt ab.Nicht Code Blocks.

LG

[RBS2]

@Zentralheizung Das Konsolenfester schließt sich. Es gibt verschiedene Tricks mit denen man das verhindern kann. Z.B. mit 'system("pause");' als letzte Anweisung.

[It0101]

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

Die exe taucht in dem Ordnern auf wo sich auch die anderen Dateien des Projekts befinden.

Also bei mir taucht die immer im Unterorder "bin" auf und nicht im Projektverzeichnis.

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

Die exe stürzt ab.Nicht Code Blocks.

Dann hast du in deinem Code einen Fehler, der dein Programm zum Absturz bringt. ( oder eben das was @RBS2 geschrieben hat ).

[Zentralheizung]

Vielen Dank für den Tipp!Ich werde direkt das was @RBS2 geschrieben hat umsetzen.DAnke auch an @It0101
MfG

[DirkB]

@Zentralheizung öffne eine Konsole, wechsele mit cd in dein Verzeichnis, starte von dort das Programm (durch eintippen des Namens).

Die Konsole unter Windows heißt cmd

[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.