10 Anfängerfehler in C++: Wie man den Code nicht kaputt macht

Online Python-Trainer für Anfänger

Lernen Sie Python einfach ohne theoretische Überlastung. Lösen Sie praktische Aufgaben mit automatischer Überprüfung und schreiben Sie Code direkt im Browser.

Kurs starten

Warum C++ selbst Erfahrene in die Knie zwingt – und Anfänger erst recht

\n

C++ ist eine gnadenlose Sprache. Sie gibt Ihnen die volle Kontrolle über den Speicher, verlangt aber auch absolute Disziplin. Wenn Sie gerade erst anfangen, C++ zu lernen, sind Sie bestimmt schon darauf gestoßen, dass das Programm kompiliert, aber mit einem Fehler abstürzt oder (noch schlimmer) ohne Fehlermeldung falsch funktioniert. Das ist nicht Ihre Schuld – es liegt in der Natur der Sprache. Aber wir können Ihnen helfen, die häufigsten Fallstricke zu vermeiden, auf die alle Anfänger treten.

\n

In diesem Artikel besprechen wir 10 kritische Fehler beim C++-Lernen, die den Code in eine höllische Mischung aus Speicherlecks und undefiniertem Verhalten verwandeln. Los geht's!

\n\n

1. Speicher freizugeben vergessen: Der klassische Speicherleck

\n

Der häufigste Anfängerfehler in C++ ist das Allozieren von dynamischem Speicher mit new und das vergessene delete. Das Programm frisst RAM wie ein Staubsauger, und Sie merken es nicht einmal.

\n

Schlechtes Beispiel:

\n
int* ptr = new int(42);\n// ... viel Code ...\n// Vergessen: delete ptr;
\n

Ergebnis: Speicherleck. Das Programm läuft, verbraucht aber mit jedem Aufruf mehr Ressourcen. In modernen Projekten ist das inakzeptabel.

\n

So beheben Sie es:

\n
    \n
  • Verwenden Sie intelligente Zeiger (std::unique_ptr, std::shared_ptr) – sie geben den Speicher automatisch frei.
  • \n
  • Wenn Sie nicht um new/delete herumkommen – setzen Sie delete immer direkt nach der letzten Verwendung.
  • \n
\n
#include <memory>\nstd::unique_ptr<int> ptr = std::make_unique<int>(42);\n// Der Speicher wird automatisch freigegeben, wenn der Gültigkeitsbereich verlassen wird
\n\n

2. Verwendung von using namespace std; im globalen Gültigkeitsbereich

\n

Diese Zeile ist wie eine Zeitbombe. Bei kleinen Übungsbeispielen funktioniert sie, aber in einem echten Projekt führt sie zu Namenskonflikten.

\n

Das Problem:

\n
#include <iostream>\n#include <vector>\nusing namespace std;\n\n// Ein Jahr später taucht eine eigene Klasse vector im Projekt auf\nclass vector { ... }; // Kompilierungsfehler!
\n

Namen aus std (z. B. vector, cout) werden global, und jede Ihrer Klassen mit demselben Namen verursacht eine Kollision.

\n

Besser so:

\n
    \n
  • Schreiben Sie explizit std::cout, std::vector.
  • \n
  • Oder verwenden Sie using std::cout; nur für bestimmte Namen.
  • \n
\n\n

3. Undefiniertes Verhalten: Ein Schuss ins Knie

\n

Der heimtückischste Fehler beim C++-Lernen ist undefiniertes Verhalten (UB – Undefined Behavior). Der Compiler gibt keinen Fehler aus, das Programm kann funktionieren – oder Ihre Festplatte löschen. Ein Scherz, aber nah an der Wahrheit.

\n

Beispiele für UB:

\n
    \n
  • Array-Index außerhalb der Grenzen: int arr[5]; arr[10] = 42;
  • \n
  • Dereferenzieren eines Nullzeigers: int* p = nullptr; *p = 5;
  • \n
  • Verwendung einer Variable vor der Initialisierung.
  • \n
\n
int x; // nicht initialisiert\nstd::cout << x; // UB: kann Müll, 0 ausgeben oder einen Absturz verursachen
\n

Tipp: Initialisieren Sie Variablen immer. Verwenden Sie std::array oder std::vector anstelle von rohen Arrays – sie überprüfen die Grenzen (im Debug-Modus).

\n\n

4. Verwechslung von Zeiger und Referenz

\n

Anfänger verstehen oft den Unterschied zwischen int* p und int& ref nicht. Fehler: Sie versuchen, eine Referenz neu zuzuweisen, oder vergessen, einen Zeiger zu dereferenzieren.

\n

Typischer Fehler:

\n
void change(int* p) {\n    p = new int(10); // ändert die lokale Kopie des Zeigers, das Original bleibt unverändert\n}\n\nint main() {\n    int* ptr = nullptr;\n    change(ptr);\n    std::cout << *ptr; // UB: ptr ist immer noch nullptr\n}
\n

Richtig: Übergeben Sie den Zeiger per Referenz (int*& p) oder verwenden Sie Referenzen, wenn die Adresse nicht geändert werden muss.

\n

Blogs

Buchempfehlungen