Hallo zusammen
Ich habe mir vor kurzem das Buch C, Programmieren von Anfang an gekauft
und nun wollte ich das erste Beispiel durcharbeiten.
Ich habe bereits Erfahrung mit Programmieren, allerdings in Delphi und
BASCOM.
Hier mein C-Code
#include <stdio.h>
main(){
printf("\nDies ist ein erstes C_Programm.\n");
printf("\nWie sie sehen, kann 'printf' ");
printf("Nicht nur Texte drucken,\n");
printf("Sondern auch rechnen.\n\n");
printf("13*7=%i \n",13*7);
}
Wenn ich die exe starte, kommt auf dem Bildschirm kurz ein kleines
schwarzes Fenster (Komandozeile), das sofort wieder verschwindet.
Woran liegts? Im Buch wird ein solches Verhalten nicht beschrieben...
Grüsse
In diesem Fenster steht Dein Text.
Damit es bleibt, musst Du Dein Programm schon aus einem solchen Fenster
starten (Start->Ausführen->cmd.exe, dann zum Programmordner mit 'cd'
navigieren).
Probier auch mal, vor die schließende geschweifte Klammer
system("pause");
zu schreiben. Wenn es keine Fehlermeldung gibt, sollte dann das Fenster
offen bleiben.
Das 'kleine schwarze Fenster' ist vermutlich die Konsole, in der Dein
Programm ausgeführt wird. Die verschwindet deswegen gleich wieder, weil
das Programm 'fertig' ist. Um das zu vermeiden gibts mehrere Optionen:
- busy-/blocking-waiting am Ende per read()/readchar()/scanf() oder
sowas in der Richtung - brrrrrr, gleich die Finger weglassen davon, das
gibt (später) nur Scherereien. Kann man aber behelfsweise z.B. in ein
'#ifdef DEBUG' verpacken weils einfach ist und schnell geht.
- Der Entwicklungsumgebung (deren Namen Du uns vorenthalten hast :-)
beibringen, dass sie das Fenster nicht gleich wieder schließen darf -
kann möglich sein, muss aber nicht
- Dem (Betriebs)System (dessen Namen Du uns vorenthalten hast :-)
beibringen, dass es das Fenster nicht gleich wieder schließen darf -
kann möglich sein, muss aber nicht
- Der sauberste Weg: Das Programm aus einer Konsole starten, das sieht
dann etwa so aus:
1
$ gcc -Wall main.c -o main
2
main.c:2: warning: return type defaults to ‘int’
3
main.c: In function ‘main’:
4
main.c:8: warning: control reaches end of non-void function
5
$ ./main
6
7
Dies ist ein erstes C_Programm.
8
9
Wie sie sehen, kann 'printf' Nicht nur Texte drucken,
10
Sondern auch rechnen.
11
12
13*7=91
13
$
HTH und HF
P.S.: printf kann nicht selbst rechnen.. jedenfalls nicht so wie im
Beispielcode suggeriert :-)
Im obigen Beispiel rechnet übrigens nicht printf(), wie es der Text
nahelegt. Es ist der C-Compiler, der 13*7 rechnet, und printf bekommt
nur noch das Ergebnis zu sehen, nicht aber die Multiplikation. Mit der
hat es rein gar nichts am Hut.
Ich hasse es, wenn eine Einführung bei solchen elementare Dingen schon
schludert. Es mag eine Kleinigkeit sein, aber gerade die sollten
stimmen.
okay, danke euch allen, das geht immer so schnell^^:D
zum Thema printf kann nicht selbst rechnen, dass sollte wohl noch
erwähnt werden im Buch;)
aus der Konsole heraus geht's danke;)
PS: OS ist Win 7 und der Compiler ist Bloodshed Dev C++
Grüsse & danke, jetzt kanns weiter gehen;)
system("pause");
Gilt nur für Windows. Macht extra nen Warte-Prozess auf.
Mag ich aber trotzdem auch, weil es nicht schwer ist sich "system" und
"pause" zu merken. Die "Eleganten", Lösungen hab ich nie im Kopf und
haben meist auch Verhalten, dass ich nicht wünsche...
Ich finds irgendwie immer wieder amüsant, dieses Phänomen. Also das, mit
dem verschwindenden Fenster.
Früher(tm) war es das natürlichste von der Welt, mit einer Konsole zu
arbeiten, und es gab wenig Probleme, die Konzepte hinter Streams,
blockierenden Eingaben, Pipelines und so weiter zu vermitteln.
Heute ist das alles so altmodisch und primitiv. Sogar so primitiv, dass
es kaum wer ernsthaft begreift...
Sven P. schrieb:
> Früher(tm) war es das natürlichste von der Welt, mit einer Konsole zu> arbeiten, und es gab wenig Probleme, die Konzepte hinter Streams,> blockierenden Eingaben, Pipelines und so weiter zu vermitteln.>> Heute ist das alles so altmodisch und primitiv. Sogar so primitiv, dass> es kaum wer ernsthaft begreift...
Früher wurden auch Bäume noch mit Äxten gefällt und das Essen wurde am
Lagerfeuer zubereitet. Das ist so typisch von alt Eingesessenen die
nicht wahrhaben wollen dass die Technik sich ändert und ihr damals so
mühsam angeeignetes Wissen nicht mehr zeitgerecht ist. Was sagen die
Profs immer? Als Ing lernt man nie aus und man muss sich ständig
weiterbilden! Anscheinend habe ich das als Student eher begriffen als
manch Alt-Ing.
Konsolenanwendungen sind Mist. Zumindestens dann wenn es modernen Ersatz
gibt. In manchen Bereichen wird unter anderem aus Kostengründen noch mit
Konsolenanwendungen gearbeitet. Das verschlingt soviel Zeit und dann
kommen noch so OpenSource-Kram dazu. Wo keiner auch nur irgenwas
dokumentiert, keine Ansprechpartner vorhanden sind und man ewig braucht
um auch nur irgendwas auf die Reihe zu kriegen. Ich habe Konsolen hassen
gerlernt.
Stimmt, kommerzielle GUI-Programme sind durchweg besser dokumentiert.
Sehr schlüssige Argumentation!
Und für die ersten Gehversuche des TE sicher vieeeel besser
verständlich.
So eine Ausgabe mit printf ist ja viel zu undurchsichtig
im Vergleich mit einem echten Windowsprogramm!
>So eine Ausgabe mit printf ist ja viel zu undurchsichtig>im Vergleich mit einem echten Windowsprogramm!
Zustimmung!
Ich pule mir gerade C# mit Hilfe eines Buchs von Dirk Louis bei.
Das erste allererste Programm wird mit Hilfe des Editors
zusammengeklickt, um zu sehen, was am Ende herauskommt (bzw. wie ein
Programm als Beispiel aussehen kann).
Danach wird erst mal auf der Konsole weitergemacht und auch deren Tücken
(kurzes Aufflackern des Fensters etc.) schön beschrieben, sowie deren
Behebenung.
Sowas fehlt den meisten Anfängern, und ich kann mir nicht vorstellen,
dass die "Cracks" hier auch gleich Fenster-Programme geschrieben haben.
Dass Konsolenanwendungen im Opensource-Bereich nicht unbedingt gut
dokumentiert sind, ist doch selbstverständlich (zumindest kann ich es
gut verstehen): Man schreibt etwas für sich selbst hilfreiches und
stellt es jedem zur Verfügung, der es vielleicht auch brauchen kann.
Dazu wird vielleicht noch kurz geschrieben, was das Tool kann, und die
Doku muss reichen; ich selbst weiss ja, wie das Tool arbeitet.
Leute, die Sachen umsonst mit dem kompletten Service haben wollen, sind
irgendwie falsch davor. (Meine persönliche Meinung)
Peter schrieb:
> Sven P. schrieb:>> Früher(tm) war es das natürlichste von der Welt, mit einer Konsole zu>> arbeiten, und es gab wenig Probleme, die Konzepte hinter Streams,>> blockierenden Eingaben, Pipelines und so weiter zu vermitteln.>>>> Heute ist das alles so altmodisch und primitiv. Sogar so primitiv, dass>> es kaum wer ernsthaft begreift...>> Früher wurden auch Bäume noch mit Äxten gefällt und das Essen wurde am> Lagerfeuer zubereitet. Das ist so typisch von alt Eingesessenen die> nicht wahrhaben wollen dass die Technik sich ändert und ihr damals so> mühsam angeeignetes Wissen nicht mehr zeitgerecht ist.
Dann beschwer dich aber nicht, wenn es dich in den Wald verschlägt und
du ohne deine moderne Technik, nur mit einer Axt und Streichhölzern
bewaffnet, zurecht kommen musst.
In einer Zeit, in der mechanische Fertigung mit CNC Maschinen gemacht
wird, ist der Umgang mit Feile, Säge und Schraubenzieher keineswegs als
unnütze Fertigkeit anzusehen.
Oder würdest du es zb begrüßen, wenn deine Kinder in der Grundschule
nicht mehr das 'kleine Einmal Eins' lernen müssen, nur weil ja doch
Computer für uns das Rechnen übernommen haben?
Peter schrieb:
> Konsolenanwendungen sind Mist. Zumindestens dann wenn es modernen Ersatz> gibt. In manchen Bereichen wird unter anderem aus Kostengründen noch mit> Konsolenanwendungen gearbeitet. Das verschlingt soviel Zeit und dann> kommen noch so OpenSource-Kram dazu. Wo keiner auch nur irgenwas> dokumentiert, keine Ansprechpartner vorhanden sind und man ewig braucht> um auch nur irgendwas auf die Reihe zu kriegen. Ich habe Konsolen hassen> gerlernt.
So ein Blödsinn habe ich schon lange nicht mehr gehört. Es gibt
wahrscheinlich nichts in der Computertechnik, was so flexibel wie die
Console ist.
Wir administrieren rund 250 Unixrechner von der Console und haben die
etwa 10 Windows 2003 Server GUI-Administration hassen gelernt.
Ich mag es, wenn ein Programm mir die Freiheit gibt, es über
Konsolenbefehle ansprechen zu können oder als GUI-Programm.
So hat man beide Welten.
Ein gutes Konzept ist doch zuerst ein Konsolenprogramm zu erstellen,
dass die Funktion bietet und diesem dann zusätzlich eine GUI
aufzusetzen.
Dass Konzept muss nicht überall sinnvoll sein. Für ein 3D-Spiel wohl
eher nicht...
Aber auch dieses kann Konsolenbefehle entgegen nehmen. Und die Spiele
haben ja sogar eine eingebaute Konsole, von daher ist die tatsächlich so
unmodern, dass sie sogar Ballerspiele besitzen ;)
Ich habe von Anfang an emacs und die bash bzw ksh genutzt. Das ist
klasse, wenn man bestimmte Anwendungen automatisieren will. Zu Zeiten
der WM oder wichtiger Fussballspiele habe ich alles an Downloads per AT
gestartet, und auch die Programmierbarkeit der shell ist immer noch
gefragt. Und ausserdem sagt mir Oberfläche, warum was abstürtzt, eine
GUI Anwendung eher nicht.
Gruss
Robert
X. H. schrieb:
> Ein gutes Konzept ist doch zuerst ein Konsolenprogramm zu erstellen,> dass die Funktion bietet und diesem dann zusätzlich eine GUI> aufzusetzen.
Das funktioniert nur sehr schlecht, weil die Denk- und
Programmiermodelle sich sehr stark unterscheiden. Konsolenanwendungen
sind üblicherweise prozedural aufgebaut, d.h., der Programmfluss ist
festgelegt. GUI-Anwendungen sind aber ereignisorientierte Anwendungen,
die auf Nachrichten vom Betriebssystem bzw. Nutzereingriffe warten.
Die "Denke" vom einen auf das andere Modell umzustellen ist durchaus
nicht einfach. Herauskommen tun dann oft Programme, die für lange Zeit
einzufrieren scheinen, weil sie irgendwelche langwierigen Dinge tun,
ohne auf Nachrichten zu reagieren. Wer "richtige" GUI-Anwendungen
gewohnt ist, hält solche Programme dann leicht für kaputt.
Rufus t. Firefly schrieb:
> Konsolenanwendungen> sind üblicherweise prozedural aufgebaut, d.h., der Programmfluss ist> festgelegt.
ist häufig so, muß aber beileibe nicht.
