printf - Ausgabefenster verschwindet sofort!

bierdosenhalter

Ich bin ein absoluter Anfänger.
Habe mich ein wenig in den ganzen Kram mit c / c++ eingelesen, aber wirkliche Vorkenntnisse habe ich nicht.
Arbeite grad Beispielprogramme durch, um ein Gefühl für die Sprache zu bekommen.

Nehmen wir mal Hello World.

/* Das Hello-World-Programm */

#include <stdio.h>

int main()

{

printf("Hello World!\n");

return 0;

}

Wieso wird mir nach dem kompilieren eigentlich kein Fenster angezeigt? Ich sehe da ganz kurz was blinken, aber in einem Bruchteil einer Sekunde ist das auch schon wieder verschwunden. Ich hab hier ein C/C++ Buch und ein Wikibook, also zwei unabhängige Quellen. Bei beiden Quelltexten der gleiche "Fehler". Compiler ist Pelles C für Windows in der Version 6.00.4.

Hab ich was übersehen? "Muss" das so sein?

SG1

bierdosenhalter schrieb:

Wieso wird mir nach dem kompilieren eigentlich kein Fenster angezeigt?

Weil Du nirgendwo Code für "mach mir ein Fenster" hast.

Was Du da hast ist ein Konsolenprogramm. Das ist dafür gedacht, in einer Konsole aufgerufen zu werden. Tust Du das nicht, macht Windows extra für Dein Programm eine auf - und wenn das Programm beendet ist, wieder zu. Also: mach selber 'ne Konsole auf, starte das Programm, werde glücklich.

Fragen kostet ja nichts. FAQ-Lesen aber auch nicht:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-111042.html

_matze

...

nachtfeuer

ja, das problem kenn ich. starte dein konsolenprogramm erst mal aus der konsole heraus. das haben die c-entwickler auch so gemacht.

du könntest alternativ noch ein kleines hallo asm-welt proggi ausprobieren.

dazu drückst du einmal die Windowstaste, gibts debug ein und bestätigst mit enter.

normalerweise öffnet sich dann das konsolenfenster von debug, als eingabepromt der blinkende unterstrich.

dort gibst du den buchstaben a ein, und bestätigst mit enter.

wenn alles passt, dann wird jetzt eine speicheradresse angezeigt und wartet auf eingaben.

hier gibst du folgendes ein, und immer mit enter bestätigen:

mov ah,09
mov dx,109
int 21
int 20
noch einmal enter drücken, um wieder in den normalen eingabemodus zu kommen.

dann gibst du ein:

e109"hallo asm-welt",24
und bestätigst mit enter
dann gibst du den buchstabe g (für go) ein und drückst wieder enter.

kurz was zu den zahlen: der befehl mov dx,109 zeigt auf die adresse der eingabe
der befehl mov ah,09 bereitet den systemaufruf für zeichenketten auf. dieser systemaufruf (int 21) (funktion 9) gibt eine zeichenkette bei adresse dx mit ende-signal 24 aus. der systemaufruf int 20 startet den service für das programmende.

man kann debug mit q wieder verlassen.

Für com programme lässt sich in windows einstellen, ob sich das fenster nach beenden schließen soll oder nicht.

falls du deine kleinen einsteiger-c proggis mal debuggen musst, dann geht das mit debug auch ganz gut. ein bißchen praktischer ist für unix-konsole-c-progs vielleicht der gdb, so wie überhaupt der c-einstieg mit linux irgendwie etwas spannender ist.
(allerdings wartet hier auch schon wieder der editor vi auf einsteiger-opfer )

Danke für die schnellen Antworten!
Ich merke gerade, dass Pelles C für Windows auch ne ganz einfache Funktion hat, direkt den Kram ins cmd Fenster zu schubsen.
Kann ich mir den Umweg darüber also sparen.

Sry wegen der FAQ, hab hier zuerst nicht ganz durchgeblickt.

Eine Frage hab ich noch, hab auch die Suchefunktion genutzt.

Ich will folgenden Code kompilieren:

#include <stdio.h>

int Main ()

{

printf("3 + 2 * 8 = %i\n", 3 + 2 * 8);

printf("(3 + 2) * 8 = %i\n", (3 + 2) * 8);

return 0;

}

Bekomme dann folgende Meldung:

Erzeugen von 1.obj.
D:\1.c(5): warning #2027: Missing prototype for 'Main'.
Fertig.

Und wenn ich ne .exe erzeugen will kommt das:

Erzeugen von 123.exe.
POLINK: error: Unresolved external symbol '_main'.
POLINK: fatal error: 1 unresolved external(s).
*** Fehlercode: 1 ***
Fertig.

Linker ist auf Console gestellt.
Stelle ich ihn auf Windows, kommt beim compilen die gleiche Meldung, beim exe erzeugen dann allerdings:

Erzeugen von 123.exe.
POLINK: error: Unresolved external symbol '_WinMain@16'.
POLINK: fatal error: 1 unresolved external(s).
*** Fehlercode: 1 ***
Fertig.

Windows CE bringt dagegen die gleichen Meldungen wie bei Console.

Native bringt wieder beim compilen das übliche, beim exe erzeugen dagegen:

Erzeugen von 123.exe.
POLINK: error: Unresolved external symbol '_DriverEntry@8'.
POLINK: fatal error: 1 unresolved external(s).
*** Fehlercode: 1 ***
Fertig.

Kann mir jemand weiterhelfen?

_matze

Die Funktion heißt main, nicht Main. C und C++ sind case-sensitiv! Wundere dich also demnächst nicht, wenn der Compiler PrintF nicht finden kann.

bierdosenhalter

Sorry für die späte Antwort, hatte zu tun.

Ja, das war ein Flüchtigkeitsfehler von mir. Danke für den Hinweis, danach funktionierte es auch!

Chris_ 0

Du kannst auch schreiben:

int main()
{
    printf("Hallo Welt!");
    getchar();
    return 0;
}

Dann schließt sich die Konsole erst nach einem Tastendruck.

MfG Chris_

system("pause");

funktioniert auch prima. heißt zwar immer, daß system nicht so schön ist, aber zum üben interessiert das doch nicht.

_matze

Chris_ schrieb:

Du kannst auch schreiben:
int main()
{
    printf("Hallo Welt!");
    getchar();
    return 0;
}
Dann schließt sich die Konsole erst nach einem Tastendruck.

MfG Chris_

Das funktioniert nur solange, bis man irgendwelche Eingabefunktionen verwendet und dann beim getchar noch irgendwas im Eingabepuffer liegt. Dann wundert man sich plötzlich, dass getchar kaputt ist...

Chris_ 0

_matze schrieb:

Das funktioniert nur solange, bis man irgendwelche Eingabefunktionen verwendet und dann beim getchar noch irgendwas im Eingabepuffer liegt.
Dann wundert man sich plötzlich, dass getchar kaputt ist...

Ja, aber man kann doch vor dem getchar()-Aufruf den Eingabepuffer leeren, oder?

_matze

Chris_ schrieb:

_matze schrieb:

Das funktioniert nur solange, bis man irgendwelche Eingabefunktionen verwendet und dann beim getchar noch irgendwas im Eingabepuffer liegt.
Dann wundert man sich plötzlich, dass getchar kaputt ist...

Ja, aber man kann doch vor dem getchar()-Aufruf den Eingabepuffer leeren, oder?

Ja sicher, aber dann solltest du das in deinem Beispiel auch direkt machen, damit er nicht in diese Falle stolpert. Er übernimmt das getchar und geht erst mal davon aus, dass er eine funktionierende Methode gefunden hat, um das Schließen der Konsole zu verhindern. Wieso sollte er annehmen, dass diese nicht unter allen Umständen funktioniert? Mit ein wenig Glück sucht er die Ursache für dasx plötzlich auftretende, direkte Schließen der Konsole überall, nur nicht beim getchar.

Chris_ 0

Ok, hatte ich nicht drangedacht :p
Also hier noch einmal mit geleertem Eingabepuffer:

int main()
{
    printf("Hallo Welt!");
    fflush(stdin);
    getchar();
    return 0;
}

Quelle: http://msdn.microsoft.com/en-us/library/9yky46tz%28VS.71%29.aspx

Ich hoffe das passt jetzt so

MfG Chris_

_matze

Leider wieder verloren! :p

Das passt zwar für den MS-Compiler, ist aber nicht im Standard definiert, daher sollte man vielleicht lieber zu allgemeingültigen Methoden greifen, die beim nächsten Compiler keine Schwierigkeiten machen. Zu dem Thema gibt es gerade einen aktuellen Thread:

http://www.c-plusplus.net/forum/viewtopic-var-t-is-273534-and-highlight-is-.html

Chris_ 0

Ok, ich geb mich geschlagen

_matze

Dazu will ich noch ergänzend sagen, dass fflush(stdin) ja nicht von Grund auf böse ist. Wenn ich kleine Testprogrämmchen mache, nutze ich es auch manchmal. Es hängt aber vom Compiler ab, ob dies erlaubt ist. Da ich ausschließlich den MS-Compiler nutze, darf ich auch stdin fflushen. Nur sollte man diese Methode nicht hier im Forum als Lösung für das Problem posten, zumal der Threadersteller ja bereits gesagt hat, dass er einen anderen Compiler benutzt. Trotzdem kannst du (genau wie ich) im Visual Studio natürlich gerne fflushen, was das Zeug hält, solange du die nicht vorhandene Portabilität im Auge behältst.