C-Direktiven anzeigen / ausblenden

[TG-01 (Gast)]

Guten Tag,

zur Zeit bin ich dabei mich zu Lernzwecken in ein recht großes Open 
Source C-Projekt einzuarbeiten.

Die Autoren des Projekts haben für ihr Programm wirklich sehr viele 
C-Direktiven verwendet.
Das Programm besteht aus mehreren C Files, zu denen widerum eine Menge 
Headerfiles gehören. So gut wie in allen Files werden sehr viele 
verschiedene  #ifdef verwendet um Codteile für verschiedene Systeme und 
Betriebsmodi zuzuschalten.

Das Problem ist, dass ich keine Übersicht darüber habe. Ich kann das 
Programm problemlos für meinen uC kompalieren und auch debuggen.
Ich würde aber gerne alle Codeteile herausschmeißen, die ich nicht 
benötige, weil sie durch die ganzen #ifdef nicht verwendet werden.

Kennt ihr eine Möglichkeit, in Visual Studio oder am besten in uVision, 
mit der ich sozusagen alle nicht verwendeten Programmteile markieren 
lassen kann ? Also ich kompaliere den Code und alles was durch die 
#define und #ifdef nicht verwendet wird, wird mir ausgegraut oder 
ähnliches ?

Oder kann ich mir eine Textdatei erstellen lassen, in der dich nur der 
Code widerfindet, der auch wirklich verwendet wird ?

Vielen Dank

[Peter II (Gast)]

TG-01 schrieb:
> Also ich kompaliere den Code und alles was durch die
> #define und #ifdef nicht verwendet wird, wird mir ausgegraut oder
> ähnliches ?

das macht bei mit das Studio schon von selber.

[TG-01 (Gast)]

In meinem uVision wird leider nicht alles ausgegraut. In Visual Studio 
schaue ich mir das dann mal an.

Kann man sich den verwendeten Code auch in einer speziellen Textdatei 
ausgeben lassen ? Also nur das, dann am Ende auch verwendet wird. Dann 
würde ich es mir im Notfall spaaren jede einzelne Datei im uVision mit 
dem Debugger durchzugehen.

[Udo S. (urschmitt)]

Was gehen sollte ist daß du dir vom Compiler eine Datei ausgegeben lässt 
die den Code nach den Ersetzungen des Präprozessors zeigt. Das ist zum 
anschauen ganz lehrreich. Man sieht da genau was aus defines #ifdefs, 
Makros etc. tatsächlich wird.

[TG-01 (Gast)]

Udo Schmitt schrieb:
> Was gehen sollte ist daß du dir vom Compiler eine Datei ausgegeben
> lässt
> die den Code nach den Ersetzungen des Präprozessors zeigt. Das ist zum
> anschauen ganz lehrreich. Man sieht da genau was aus defines #ifdefs,
> Makros etc. tatsächlich wird.

Vielen Dank. Das ist genau das, was ich suche.

Wie heißt so eine Datei denn ? Dann kann ich mal danach suchen.

[Karl H. (kbuchegg)]

TG-01 schrieb:

> Vielen Dank. Das ist genau das, was ich suche.

Warts erst mal ab. (*)

> Wie heißt so eine Datei denn ? Dann kann ich mal danach suchen.

Beim gcc heisst die entsprechende Option -E

Und wenn man nicht weiß, wie eine Datei heißt (bzw. welche Endung sie 
kriegt), dann kann man das pragmatisch machen. Schalte in deiner IDE die 
entsprechende Option ein, die den Preprozessor-Output aktiviert und sieh 
danach (mit dem Explorer) auf deinen Entwicklungsverzeichnissen nach, 
welche Datei rein vom Timerstamp (also Datum und Uhrzeit) als Kandidaten 
in Frage kommen. So viele neue Dateien sind es ja nicht und von den 
meisten weißt du ja, was drinnen steht. Alle die du nicht kennst, sind 
damit erst mal Kandidaten. Und das eine Datei, in der der Preprozessor 
ALLE Symbole aufgelöst hat, nicht gerade klein sein wird, kann man sich 
auch vorstellen.

Man muss nicht alles wissen. Man muss sich nur zu helfen wissen.


(*) Edit:
Warts erst mal deswegen ab, weil der Preprozessor ALLES auflöst. Auch 
die Symbole und sonstigen Ersetzungen sowie alle includes, die du 
eigentlich nicht aufgelöst haben willst. Soll heißen: Das Ergebnis wird 
groß - richtig groß. Wenn du davon träumst, dass du dieses Ergebnis 
einfach als deinen neuen Source Code nimmst - vergiss es gleich wieder.
Aber lehrreich ist es allemal, sich das mal anzusehen, was da eigentlich 
während des Preprozessor Laufes alles passiert und ersetzt wird. Und 
manchmal muss man auch diesen Weg gehen, wenn es sich nicht vermeiden 
lässt und man anders nicht mehr raus kriegt, wie eine bestimmte 
Preprozessor-Operation zustande kommt. Dann ist es gut, wenn man seine 
Werkzeuge beherrscht und mit ihnen umgehen kann. Wobei man höchst 
wahrscheinlich nicht gleich mit einem Monsterprojekt loslegt, um den 
Umgang zu lernen. Ein Projekt mit einem kleinen C-Code tut es ja auch um 
sich erst mal mit den Basics in der Bedienung vertraut zu machen.


Und PS: es heißt 'compilieren' und nicht 'kompalieren'. Das kommt aus 
dem englischen 'to compile' - sammeln, zusammenstellen, übersetzen.