erstes C_Programm, erstes Problem

[Marius (Gast)]

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

[Hc Z. (mizch)]

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

[Klaus W. (mfgkw)]

.. und dann das Programm starten.

[Dussel (Gast)]

Probier auch mal, vor die schließende geschweifte Klammer

system("pause");

zu schreiben. Wenn es keine Fehlermeldung gibt, sollte dann das Fenster 
offen bleiben.

[g457 (Gast)]

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:

$ gcc -Wall main.c -o main
main.c:2: warning: return type defaults to ‘int’
main.c: In function ‘main’:
main.c:8: warning: control reaches end of non-void function
$ ./main 

Dies ist ein erstes C_Programm.

Wie sie sehen, kann 'printf' Nicht nur Texte drucken,
Sondern auch rechnen.

13*7=91 
$

HTH und HF

P.S.: printf kann nicht selbst rechnen.. jedenfalls nicht so wie im 
Beispielcode suggeriert :-)

[Hc Z. (mizch)]

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.

[Marius (Gast)]

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;)

[X. H. (shadow0815)]

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

[Klaus W. (mfgkw)]

getchar() konnte ich mir bisher auch merken, obwohl ich ein
schlechtes Gedächtnis habe.

[c# please (Gast)]

Console.Readline();

[Rufus Τ. F. (rufus)]

Hinweise auf C# sind in einem Thread, in dem es um C geht, nicht 
hilfreich.

[Sven P. (Gast)]

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

[X. H. (shadow0815)]

>getchar() konnte ich mir bisher auch merken, obwohl ich ein
>schlechtes Gedächtnis habe.

Das ist kein press anykey, das ist ein Press Enter...

[Klaus W. (mfgkw)]

ich hatte mal gelesen, Enter wäre die Anikei-Taste?

[Peter (Gast)]

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.

[Klaus W. (mfgkw)]

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!

[STK500-Besitzer (Gast)]

>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)

[Flipcode (Gast)]

und ich werde nie begreifen warum die leute immernoch devcpp empfehlen 
und oder verwenden.

[Karl H. (kbuchegg)]

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?

[B. M. (Gast)]

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.

[X. H. (shadow0815)]

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 ;)

[R. F. (rfr)]

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

[Rufus Τ. F. (rufus)]

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.

[Klaus W. (mfgkw)]

Rufus t. Firefly schrieb:
> Konsolenanwendungen
> sind üblicherweise prozedural aufgebaut, d.h., der Programmfluss ist
> festgelegt.

ist häufig so, muß aber beileibe nicht.

[Rufus Τ. F. (rufus)]

Das ist aber bei Programmieranfängern eher eine Zufallserscheinung denn 
gewollt.