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?
Weil da (praktisch) kein ausführbarer Code drin ist, nur Deklarationen und sowas. Infos für den Compiler, die nicht direkt im Executable landen.
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.
die antworten kommen ja super schnell reingeflogen :) Im Binärfile steht doch aber auch sowas wie Deklarationen von RAM-Variablen etc. oder nicht?
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.
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.
Nein, natuerlich nicht. Die Cpu kennt keine Datentypen, nur unstruktionen
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.
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?
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.
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.
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
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.
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.
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.
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.." :-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.