MINT lernen

Übungen: Übersetzen

Ein Semikolon zu wenig, ein Buchstabe vertauscht — findest du heraus, an welcher Station die Übersetzung stoppt?

Dein Fortschritt:
0 / 0 Aufgaben
1

Übungsaufgaben

Zehn Übungen zum Klicken, Zuordnen, Nachverfolgen und Knobeln — von AFB I bis AFB III. Jede Übung gibt dir sofort Rückmeldung; wenn du nicht weiterkommst, helfen dir die gestuften Tipps.

A1
Das Grundgerüst lesen
AFB I

Jedes C-Programm besteht aus denselben Bausteinen. Ordne jedem Baustein seine Aufgabe zu.

Ansatz: Fang mit den beiden eindeutigsten an: Was bedeutet das Doppelkreuz #, und was macht return in anderen Sprachen?
Weiter: /* … */ und // sind beides Kommentare — der eine endet erst bei */.
A2
Vom Quelltext zur Datei
AFB I

Beim Befehl gcc wetter.c -o wetter passiert mehr, als man sieht. Gib die fehlenden Fachbegriffe an — ein Wort bleibt übrig.

Wort anklicken, dann Lücke anklicken (oder umgekehrt) — mit Tab und Enter geht es genauso. Ein Klick auf eine gefüllte Lücke legt das Wort zurück.

Zuerst ersetzt der jede #include-Zeile durch den Inhalt der Header-Datei. Dann prüft der die Syntax und übersetzt den Text in Maschinencode; es entsteht eine (wetter.o). Der fügt den Maschinencode von printf aus der Bibliothek hinzu. Am Ende liegt die wetter vor, die du mit ./wetter startest.

Der Ablenker ist „Interpreter“: So arbeitet Python — es übersetzt beim Ausführen Zeile für Zeile. Bei C ist die Übersetzung vor dem Start abgeschlossen. Oft verwechselt: Compiler und Linker. Der Compiler kennt nur deine Datei; erst der Linker holt fertige Bibliotheksfunktionen wie printf dazu.
Ansatz: Die Stationen laufen in der Reihenfolge Präprozessor → Compiler → Linker ab.
Weiter: Die Endung .o steht für „object“ — das Zwischenergebnis des Compilers.
A3
Stimmt's? — gcc und Quelltext
AFB I

Fünf Behauptungen rund um das Übersetzen. Nenne jeweils, ob sie stimmt.

Fünf Aussagen nacheinander. Eine falsche Einschätzung reicht — dann startest du die Serie mit „Neue Runde“ neu.
Aussage 1 von 5

Die gefährlichste Fehlvorstellung ist die erste: Nach gcc ist nur eine Datei entstanden, ausgeführt wurde noch nichts. Wer danach den Quelltext ändert und nur ./wetter tippt, sieht weiterhin das alte Verhalten.
Ansatz: Trenne zwei Schritte: Übersetzen (gcc) und Ausführen (./name).
Weiter: Warnungen sind Hinweise auf verdächtige Stellen; ein Fehler dagegen verhindert, dass eine Datei entsteht.
A4
Arbeitsablauf mit Fehlermeldung
AFB II

Lina schreibt ein Programm uhr.c. Beim ersten Übersetzen meldet gcc einen Fehler. Stelle ihren Arbeitsablauf vom Schreiben bis zur richtigen Ausgabe in der richtigen Reihenfolge dar.

Ziehe die Karten in die richtige Reihenfolge — mit der Tastatur: ↑/↓ verschiebt, Shift+↑/↓ wechselt nur den Fokus.
1Quelltext im Editor schreiben und als uhr.c speichern
2gcc -Wall uhr.c -o uhr
3Erste Fehlermeldung lesen: Datei, Zeile, Art des Fehlers
4Fehler im Quelltext korrigieren und Datei speichern
5gcc -Wall uhr.c -o uhr (erneut)
6./uhr
Am häufigsten verrutscht das Speichern: Wer korrigiert, aber nicht speichert, übersetzt die alte Datei und bekommt dieselbe Meldung noch einmal. Und ./uhr gehört ans Ende — vor dem zweiten Übersetzen würde es noch gar keine Datei uhr geben, weil der erste Versuch gescheitert ist.
Ansatz: Überlege, was nach dem ersten, fehlgeschlagenen gcc-Aufruf überhaupt schon existiert.
Weiter: gcc liest die gespeicherte Datei von der Festplatte — nicht das, was gerade im Editorfenster steht.
A5
Wer meldet den Fehler?
AFB II

Jede Karte beschreibt einen Fehler in einem sonst korrekten Programm. Ordne jede Karte der Station ein, an der der Fehler auffällt.

Ziehe jede Karte in den passenden Korb — oder wähle sie mit Enter aus und drücke dann die Ziffer des Korbs (0 legt sie zurück).
1Präprozessor
2Compiler
3Linker
4keine Meldung
Der Tippfehler mian ist die Falle: Syntaktisch ist das eine völlig korrekte Funktion, deshalb meckert der Compiler nicht. Erst der Linker merkt, dass es kein main gibt, und meldet undefined reference to `main'. Ein fehlendes \n oder ein zu großer Kommentar ist gar kein Fehler für gcc — das Programm läuft, gibt aber etwas anderes aus als geplant.
Ansatz: Der Präprozessor kümmert sich nur um Zeilen mit #. Der Compiler prüft Schreibweise und Klammern.
Weiter: Der Linker sucht Funktionen zusammen — auch die Funktion, mit der alles beginnt.
A6
In welcher Zeile steht das?
AFB II

Das Programm der Schul-Mensa zeigt den Tagesplan an.

C · mensa.c
#include <stdio.h>

int main(void) {
    printf("Mensa\n");
    printf("Heute: ");
    printf("Nudeln\n\n");
    printf("Preis: 3 Euro\n");
    return 0;
}

Bestimme, in welcher Zeile der Konsole der Text Preis: 3 Euro erscheint.

Überlege selbst und trage die Zeilennummer ein — Enter prüft direkt.
Ausgabe: Zeile 1 „Mensa“, Zeile 2 „Heute: Nudeln“, Zeile 3 leer, Zeile 4 „Preis: 3 Euro“. Typischer Fehler: vier printf-Aufrufe = vier Zeilen. Eine neue Zeile entsteht aber nur durch \n: „Heute: “ hat keins, deshalb klebt „Nudeln“ dahinter — und \n\n erzeugt eine Leerzeile.
Ansatz: Schreibe die Ausgabe Zeichen für Zeichen auf ein Blatt und beginne bei jedem \n eine neue Zeile.
Weiter: Zwischen „Heute: “ und „Nudeln“ steht kein \n.
A7
Grundgerüst und Befehle ergänzen
AFB II

Das Programm ampel.c soll die Zeile Ampel: gruen ausgeben. Ergänze den Quelltext und die beiden Befehle in der Konsole.

Wähle in jedem Menü den passenden Eintrag und prüfe dann alle auf einmal.
C · ampel.c
#include <>

int (void) {
    printf("Ampel: gruen");
    return ;
}
Konsole
$ gcc -Wall  -o 
$ 
Verwechselt wird am häufigsten die Reihenfolge im gcc-Befehl: Zuerst kommt die Quelldatei ampel.c, hinter -o der Name der neuen Datei. Wer gcc ampel -o ampel.c tippt, bekommt im besten Fall eine Fehlermeldung — im schlechtesten überschreibt er seinen Quelltext. Beim Zeilenumbruch zählt die Richtung des Strichs: \n mit Backslash.
Ansatz: -o heißt „output“: Dahinter steht, wie die erzeugte Datei heißen soll.
Weiter: Gestartet wird die Datei im aktuellen Ordner — dafür steht ./.
A8
Fehlersuche: Bewässerung
AFB III

Das Programm der Pflanzenbewässerung soll vier Statuszeilen ausgeben, lässt sich aber nicht sauber übersetzen. Überprüfe den Code — drei Zeilen sind fehlerhaft.

In diesem Code stecken Fehler. Klicke genau die fehlerhaften Zeilen an — die richtigen musst du stehen lassen.
Die Falle ist Zeile 5: Die Leerzeichen um Klammern und Semikolon sehen ungewohnt aus, sind aber erlaubt — C ignoriert sie. Zeile 6 dagegen fällt auf, weil gcc nur eine Warnung ausgibt (character constant too long); neuere gcc-Versionen brechen sogar ab. Lies Fehlermeldungen von oben: Nach der Korrektur von Zeile 1 erscheint erst die Meldung zu Zeile 4.
Ansatz: Prüfe jede Zeile auf die drei Klassiker: vollständiger Header-Name, Semikolon am Ende, Art der Anführungszeichen.
Weiter: Leerzeichen zwischen Namen, Klammern und Semikolon sind in C kein Fehler.
A9
C und Python im Vergleich
AFB III Mix

Zwei Programme mit derselben Ausgabe — links kennst du die Sprache schon.

Python · gruss.py
print("Guten Morgen")
print("Klasse 9b")
C · gruss.c
#include <stdio.h>

int main(void) {
    printf("Guten Morgen\n");
    printf("Klasse 9b\n");
    return 0;
}

Vergleiche die beiden Sprachen und markiere alle Aussagen, die zutreffen.

Mehrere Antworten sind richtig. Markiere alle zutreffenden und klicke dann auf „Prüfen“.
Vorsicht bei der fünften Aussage: Genau so verhält sich Python — ein falscher Name fällt dort erst beim Erreichen der Zeile auf. In C bemerken Compiler und Linker den Fehler, bevor das Programm überhaupt entsteht. C startet nicht oben in der Datei, sondern in main; printf gibt nur aus, was im Text steht — ohne \n kein Umbruch.
Ansatz: Denke an die Übersetzungsstraße: Was ist schon passiert, bevor ./gruss läuft?
Weiter: Wo steckt in gruss.c das \n — und warum braucht Python keins?
A10
Welche Version läuft?
AFB III Trick

Lina übersetzt ihre Uhr. Zuerst gibt uhr.c den Text Version 1 aus. Nach dem zweiten Befehl ändert sie im Editor Version 1 in Version 2 und speichert.

Konsole
$ gcc -Wall uhr.c -o uhr
$ ./uhr                  ← A
   (uhr.c ändern und speichern)
$ ./uhr                  ← B
$ gcc uhr.c
$ ./uhr                  ← C
$ ./a.out                ← D

Analysiere die Sitzung: Welche Version meldet sich bei A, B, C und D?

Arbeite die Kette Schritt für Schritt ab: Erst wenn ein Schritt stimmt, wird der nächste freigeschaltet. Trag z. B. Version 1 ein, Enter prüft.
  1. Ausgabe bei A
  2. Ausgabe bei B
  3. Ausgabe bei C
  4. Ausgabe bei D
Zwei Fallen: Bei B ist der Quelltext zwar geändert, aber noch nicht übersetzt — uhr ist die alte Datei. Bei C wurde zwar übersetzt, aber ohne -o uhr. Dann nennt gcc das Ergebnis a.out und lässt uhr unverändert. Die neue Version steckt also nur in a.out.
Ansatz: Frage bei jedem ./…: Wann wurde genau diese Datei zuletzt erzeugt — und aus welchem Quelltext?
Weiter: Ohne -o schreibt gcc immer in die Datei a.out.