Hallo,
Ich möchte ein lauffähiges Programm erstellen. Mit einem Compiler habe
ich schon mal Quelldateien übersetzt.
Manche Quellen bestehen nur aus einer "Main", andere enthalten noch
"make" wiederum andere noch diverse .h Dateien.
Frage 1: Wozu sind diese Dateien erforderlich?
Frage 2: wie programmiert man diese?
Verständliche Antworten auf diese grundsätzlichen Fragen habe ich
nirgendwo finden können.
Anfänger schrieb:> Verständliche Antworten auf diese grundsätzlichen Fragen habe ich> nirgendwo finden können.
Diese Aussage kann NUR bezweifelt werden...
Anfänger schrieb:> Manche Quellen bestehen nur aus einer "Main", andere enthalten noch> "make"
Eine Quelldatei enthält kein make.
> wiederum andere noch diverse .h Dateien.>> Frage 1: Wozu sind diese Dateien erforderlich?
Main: Ist die erste Funktion, die beim Starten des Programms aufgerufen
wird.
make: Wird verwendet um die Quelldateien zu übersetzen. Makefiles sind
also selbst keine Quellen.
.h: So genannte Header-Dateien. Dienen dazu, um Deklarationen von
Funktionen oder Konstanten für mehr als eine Quelldatei verfügbar zu
machen.
> Frage 2: wie programmiert man diese?>> Verständliche Antworten auf diese grundsätzlichen Fragen habe ich> nirgendwo finden können.
Solche Dinge werden in jedem Buch für Anfänger erklärt.
Dann gib uns doch mal Fakten:
Welche Bücher hast du bisher dazu gelesen? Dann könnte man die
Autoren/Verlage anschreiben, dass die Bücher verbessert werden können.
So wäre allen geholfen.
Die Frage ist doch durchaus berechtigt. Und gar nicht so einfach zu
beantworten.
Die Beispiele der Lehrbücher sind zu klein. Da sind mehrere Dateien
eigentlich unsinnig. Da erkennt man nicht, wofür das gut sein soll.
Die Beispiele aus der Realität sind so misslungen - die sollte man nicht
als Vorbild nehmen.
Da hat man ein Henne-Ei Problem. Man muss erst mal selbst erlebt haben,
wie ein grösseres Programm im Chaos versinkt, bevor man überhaupt
versteht, wo das Problem liegt.
Trotz der ganzen Lehrbücher findet man so selten sinnvoll auf Dateien
aufgeteilte Programme. Offensichtlich taugen die Erklärungen in den
Anfänger-Lehrbüchern nichts.
Mir ist aufgefallen, dass viele "Anfänger"-Tutorials Header-Dateien gar
nicht erwähnen, sondern immer alles in die .c schreiben. Wenn das mal
nicht funktioniert, weil der Compiler meckert, dann schreiben sie lieber
Funktions prototypen "void a(int hallo);" in die .c Dateien ganz oben
rein.
So kann das dann nichts werden.
Wozu man die .h braucht? Es wurden schon Links dazu gegeben. Meiner
Ansicht nach gibt es rein theoretisch nur einen Grund: Weil man die .c
Dateien nicht hat! Das dürfte recht selten bei privaten Projekten
vorkommen, es ist aber im Profibereich ganz normal, eine Library
einzukaufen, die dann als .lib oder .o oder .a kommt. Damit man die
Funktionen darin überhaupt nutzen kann, und der Lizenzgeber seinen
Quellcode nicht heraus geben muss, benötigt man die Header.
TMK schrieb:> Meiner> Ansicht nach gibt es rein theoretisch nur einen Grund.
Deiner ein theoretischen Ansicht nach mag das so sein.
Rein praktisch wird das gemacht, um überhaupt real nutzbare Programme
jenseits von "Hello world" und der Anfänger-Tutorial-Größe sinnvoll
erstellen zu können.
Ohne Code-Gliederung und sinnvolle Aufteilung geht sowas nicht.
Oliver
Anfänger schrieb:> Verständliche Antworten auf diese grundsätzlichen Fragen habe ich> nirgendwo finden können.
Dann hast du nach den falschen Begriffen gesucht.
Das Stichwort hier heißt "Modularisierung", d.h. die Unterteilung eines
großen Programms in mehrere getrennt zu kompilierende Einheiten, die
jeweils aus Implemetation (.c-Datei) und Schnittstelle (.h-Datei)
bestehen und deren Erstellungsprozess (Kompilieren und Linken) meist
durch make gesteuert wird.
Google liefert dir auf die Anfrage nach
Modularisierung in C
hin fast beliebig viele weitere Informationen zu diesem Thema.
Oliver S. schrieb:> Deiner ein theoretischen Ansicht nach mag das so sein.
Du hast das "theoretisch" falsch verstanden. Ich meinte damit, dem
C-Compiler ist es egal. Dass man Programme in sinnvolle Zeile zerbrechen
sollte, die in sich in gewisser Weise abgeschlossen sind, versteht sich
von selbst.
Yalu X. schrieb:> Anfänger schrieb:>> Verständliche Antworten auf diese grundsätzlichen Fragen habe ich>> nirgendwo finden können.>> Dann hast du nach den falschen Begriffen gesucht.>
Das ist das Los aller Änfänger. :(
Zur Zeit im Urlaub; werde danach mal den Stichpunkten weiter suchen.
Der anfang ist schon mal gemacht. Melde mich später
Noch einer schrieb:> Man muss erst mal selbst erlebt haben,> wie ein grösseres Programm im Chaos versinktNoch einer schrieb:> Offensichtlich taugen die Erklärungen in den> Anfänger-Lehrbüchern nichts
Du meinst also ernsthaft, ein Lehrbuch müsste chaotische Programme
auflisten, damit ein Anfänger das Problem begreift? Vielleicht solltest
du dich bei einem Verlag bewerben. Learning by Chaos wäre mal was neues.
Georg
Georg schrieb:> Du meinst also ernsthaft, ein Lehrbuch müsste chaotische Programme> auflisten, damit ein Anfänger das Problem begreift?
In gewissen Maßen ist das tatsächlich nötig, damit der Anfänger die
Chance hat, zu begreifen, warum man eine bestimmte Vorgehensweise
einer anderen gegenüber bevorzugen soll.
Ihm immer nur mitzuteilen "mach es so, weil es anders böse ist" ist
nicht hilfreich, er muss erkennen, warum es böse ist, es anders zu
machen.
Georg schrieb:> Learning by Chaos wäre mal was neues.
Das erste Mal, wenn du ein von dir geschriebenes Programm nicht mehr
verstehst und deswegen mehrere Wochen Arbeit wegwerfen musst, erkennst
du die Bedeutung hinreichender Dokumentation.
Das erste Mal, wenn du wegen einer mangelhaften Struktur große Teile
eines Programms wegwerfen musst, erkennst du die Bedeutung einer guten
Strukturierung (oder den Wert eines Refactorings).
Erfahrung ist Wissen über Dinge, die nicht funktionieren.
Georg schrieb:> Du meinst also ernsthaft, ein Lehrbuch müsste chaotische Programme> auflisten, damit ein Anfänger das Problem begreift?
Du wirst lachen: Gleich für mehrere Programmiersprachen existieren
Bücher, die genau das machen. Es wird Code mit überwiegend "typischen"
Problemen (mehr oder weniger subtile Programmfehler, schlechte Struktur
etc.) gezeigt, die man finden und korrigieren soll. Vielleicht nicht
besonders sinnvoll für absolute Anfänger, aber für "leicht
Fortgeschrittene" gar nicht so schlecht.