Gast
#2736746
Hi, habe ein C-Projekt bei dem ein Headerfile 1.2MB groß ist. Wieso ist die Binärdatei nach dem Compiliervorgang aber nichtmal so groß wie diese eine Headerdatei?
Gast
#2736748
Weil da (praktisch) kein ausführbarer Code drin ist, nur Deklarationen und sowas. Infos für den Compiler, die nicht direkt im Executable landen.
Gast
#2736750
weil 1,2MB kommentare in der header datei sind.
Gast
#2736752
Weil eine Headerdatei in einem sauber (bzw. klassisch) strukturierten Projekt keinen Beitrag zum Speicherverbrauch liefert. Denn die Headerdatei enthält nur Deklarationen (und keine Definitionen), und die brauchen keinen Speicher. C-Buch...
Warscheinlich sind da auch viele Daten in Hex-Schreibweise drin, das kann schonmal um Faktor 5-6 aufblähen alleine durch die Schreibweise.
Gast
#2736765
die antworten kommen ja super schnell reingeflogen :) Im Binärfile steht doch aber auch sowas wie Deklarationen von RAM-Variablen etc. oder nicht?
Gast
#2736774
Das ist ein Missverständnis: Der Begriff "Deklarationen" bezieht sich auf den Quellcode. Es gibt keinen Grund warum Deklarationen noch in dem Kompilat enhalten sein sollten.
Gast
#2736775
joli schrieb: > Im Binärfile steht > doch aber auch sowas wie Deklarationen von RAM-Variablen etc. oder > nicht? nein, es stehen keine namen von Variablen drin. Sven P. schrieb: > Weil eine Headerdatei in einem sauber (bzw. klassisch) strukturierten > Projekt keinen Beitrag zum Speicherverbrauch liefert. das stimmt so aber nicht. #define Text1 "Das ist ein Text" dies hat eine diekte auswirkung auf die größe vom Binary file (wenn auch das define verwendet wird) und das ist sehr wohl eine saubere Programmierung.
Gast
#2736776
Nein, natuerlich nicht. Die Cpu kennt keine Datentypen, nur unstruktionen
Gast
#2736781
Peter II schrieb: > joli schrieb: >> Im Binärfile steht >> doch aber auch sowas wie Deklarationen von RAM-Variablen etc. oder >> nicht? > nein, es stehen keine namen von Variablen drin. Das stimmt so nicht. Im Kompilat können sehr wohl Symbole enthalten sein, etwa Debugging-Symbole. Üblicherweise strippt man die aber oder sie gehen automatisch ab, wenn man die zum Brennen nötigen Sektionen extrahiert. Manchmal bleiben die Symbole aber auch drin, etwa wenn dynamisch gelinkt werden soll. > Sven P. schrieb: >> Weil eine Headerdatei in einem sauber (bzw. klassisch) strukturierten >> Projekt keinen Beitrag zum Speicherverbrauch liefert. > das stimmt so aber nicht. > > #define Text1 "Das ist ein Text" > > dies hat eine diekte auswirkung auf die größe vom Binary file (wenn auch > das define verwendet wird) und das ist sehr wohl eine saubere > Programmierung. Nein, hat es nicht. Es hat garkeine Auswirkung auf die Größe des Kompilates.
Gast
#2736787
Sven P. schrieb: > Nein, hat es nicht. Es hat garkeine Auswirkung auf die Größe des > Kompilates. klar wenn der text länger wird, wird auch die binary datei größer. Oder Was glaubst du wo der Text gespeichert wird?
Gast
#2736799
Peter II schrieb: > Sven P. schrieb: >> Nein, hat es nicht. Es hat garkeine Auswirkung auf die Größe des >> Kompilates. > > klar wenn der text länger wird, wird auch die binary datei größer. Oder > Was glaubst du wo der Text gespeichert wird? Nirgendwo, das ist ja der Knackpunkt. Du kannst beliebig viel Text und Daten in irgendwelche Präprozessor-Konstanten (#define) verpacken und es wird effektiv keine Auswirkung auf das Kompilat haben.
Gast
#2736804
Sven P. schrieb: > Nirgendwo, das ist ja der Knackpunkt. Du kannst beliebig viel Text und > Daten in irgendwelche Präprozessor-Konstanten (#define) verpacken und es > wird effektiv keine Auswirkung auf das Kompilat haben. ich habe geschrieben wenn das define auch verwendet wird. header: #define TEXT "Das ist ein Text" c quelle print( TEXT ); dann hat die headerdatei auswirkung auf die codegröße.
Gast
#2736817
Da könnte man jetzt prima Haare spalten... Aber gut, im einfachsten Fall hast du ja Recht.
Eine Header-Datei erzeugt genau 0 Byte Code und verbraucht genau 0 Byte RAM. Sie macht ja nur Funktionen oder Variablen für den Compiler bekannt. Erst das C-File oder eine Lib braucht wirklich Resourcen. Peter
Gast
#2736828
Peter Dannegger schrieb: > Eine Header-Datei erzeugt genau 0 Byte Code und verbraucht genau 0 Byte > RAM. richtig, aber sie kann auswirkung auf die größe der erzeugten binary datei haben. Einfachste fall ist wenn man eine variable von uint8 auf uint32 ändert.
Gast
#2736833
Peter II schrieb: > Peter Dannegger schrieb: >> Eine Header-Datei erzeugt genau 0 Byte Code und verbraucht genau 0 Byte >> RAM. > > richtig, aber sie kann auswirkung auf die größe der erzeugten binary > datei haben. Einfachste fall ist wenn man eine variable von uint8 auf > uint32 ändert. Jetzt reitest du dich wieder rein. Der Speicher für die Variable wird (klassisch) in der C-Quelldatei reserviert, und zwar durch die Definition der Variablen mit einem Typ. Im Header steht bestenfalls noch eine Deklaration für diese Variable, und zwar mit dem 'extern'-Schlüsselwort. Die braucht keinen Speicher, und wenn sie im Widerspruch zu irgendeiner Definition steht, gibt es eine Fehlermeldung.
Gast
#2736835
Sven P. schrieb: > Jetzt reitest du dich wieder rein. > Der Speicher für die Variable wird (klassisch) in der C-Quelldatei > reserviert, und zwar durch die Definition der Variablen mit einem Typ. nein, wenn es eine stuct ist und diese in verschienden c datein verwendet wird, dann hat das sehr wohl eine auswirkung auf die codegröße. bei MS gibt es z.b auch defines in der form MAX_PATH_LEN und im code hat man dann etwas stehen wie char x[MAX_PATH_LEN] und damit hat auch wieder die header datei eine direkte auswirkung auf die codegröße.
Gast
#2736844
Das hatten wir ja eben schon, ja, im einfachsten Fall hast du da Recht. Ich möchte da nicht Haare spalten, ich weiß ja was du meinst. Ich habe einen Professor, der bringt das in so einer Situation sehr treffend auf den Punkt: "Ich könnte jetzt einfach 'ja' sagen, aber.." :-)