Eclipse 3.7 kann Typen in C ++ Editor nicht auflösen

Ich habe kürzlich von Eclipse 3.6 zu Eclipse 3.7 gewechselt, das ich für die C ++ - Entwicklung in Ubuntu 11.04 verwende.

Mit Version 3.6 hatte ich keine großen Probleme, außer dass ich immer einige Probleme mit dem Indexer hatte. Ab Version 3.7 werden nicht aufgelöste Typen als Fehler markiert. Da der Indexer mich noch mehr zu mögen scheint, kennt meine Eclipse offenbar keine Typen wieuint16_t odersize_t.

Im Gegensatz zu den angezeigten Fehlern im Code-Editor hat mein Compiler keine Probleme mit dem Kompilieren des Codes und dem Auflösen aller Symbole und Typen. Dies scheint also ein Problem der IDE selbst zu sein.

Gibt es Möglichkeiten, dieses Verhalten zu vermeiden, da alle roten Unterstreichungen meinen Code immer unlesbarer machen ...?

Aktualisieren:

Okay, mit einigen Nachforschungen und der Antwort von Dennis habe ich herausgefunden, dass ich einige Pfade hinzufügen mussProject Properties/ C/C++ General/ Paths and Symbols

Da ich für einen PowerPC anstelle eines I32-Ziels baue, kann ich nicht einfach hinzufügen/usr/include . Stattdessen musste ich hinzufügen

/usr/powerpc-linux-gnu/libc/usr/include

für alle Standardüberschriften (wiestdint.h). Ich brauchte auch:

/usr/lib/gcc/powerpc-linux-gnu/4.5.1/include

für diestdarg.h.

Jetzt sind fast alle Fehler verschwunden. Die einzige Funktion, die mich noch stört, istprintf aus dem Headerstdio.h. Ich habe es nachgeschlagen und die Header-Datei selbst liegt in den enthaltenen Pfaden. Trotzdem bekomme ich einen Fehler der besagtFunction printf could not be resolved. Ich möchte noch einmal darauf hinweisen, dass dies nur Fehler sind, die von Eclipse angezeigt werden. Die Kompilierung selbst funktioniert einwandfrei.

Das wirft also tatsächlich 3 Fragen auf:

In den Projekteigenschaften wird diePaths and Symbols Abschnitt stimmt mit den Include-Pfaden aus dem übereinC++ Build/Settings/C++ Includes Sektion. Dies bedeutet, dass das Hinzufügen / Löschen eines Pfads in einem dieser Abschnitte sich direkt auf die Eingabe der anderen Abschnitte auswirkt. Seit derC++ Includes direkt mit dem Compiler kohärent Ich frage mich, warum der Compiler richtig kompilieren kann (und die Header findet), auch wenn sie nicht als Pfad an ihn übergeben werden? Gibt es eine Art Standardpfad, den GCC verwendet, von dem ich nichts weiß?

Warum findet er nichtprintf in der Finsternis? Die Headerdateistdio.h ist enthalten und enthält auch die Deklaration vonprintf - Warum sagt mir der Eclipse-Code-Editor, dass er das Problem nicht lösen kann?

Warum sind die Header-Dateien so stark aufgeteilt? Ich bin mir bewusst, dass ich andere Header-Dateien benötige, wenn ich für ein anderes Traget (z. B. PowerPC) baue. Aber warum trennt das GNU GCC diese Header in verschiedene Verzeichnisse?

Antworten auf die Frage(3)

Ihre Antwort auf die Frage