Sehr große 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 1,2MB kommentare in der header datei sind.

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...

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.

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.." :-)