Allg. Frage zu .h-Dateien
-
ten schrieb:
Entenwickler schrieb:
Extrem kleine und kurze Funktionen kann man direkt im Header implementieren dass der Compiler sie inlinen kann.
dafür braucht's ab ein non-standard keyword wie '__forceinline' oder so, sonst wird da doch 'ne funktion draus und wenn man dann die .h in mehr als ein .c-file includet gibts probleme beim linken
ne, das Keyword heißt inline und das ist ziemlich Standard, sowohl in C++, als auch C.
-
Ich glaube das kennt er schon. Und nein, ein __forceinline wäre nicht dasselbe wie ein inline. Aber das weisst du auch
-
rüdiger schrieb:
ten schrieb:
Entenwickler schrieb:
Extrem kleine und kurze Funktionen kann man direkt im Header implementieren dass der Compiler sie inlinen kann.
dafür braucht's ab ein non-standard keyword wie '__forceinline' oder so, sonst wird da doch 'ne funktion draus und wenn man dann die .h in mehr als ein .c-file includet gibts probleme beim linken
ne, das Keyword heißt inline und das ist ziemlich Standard, sowohl in C++, als auch C.
ich dachte immer, ein C-compiler kann 'inline' auch missachten
-
obbba schrieb:
Aber das gleiche kann mir doch auch mit normalen includierten .c oder .cpp Dateien passieren.
Definiert man da auch für jede Datei eine Konstante?.c und .cpp-Dateien inkludiert man nicht!
@net
und __forceinline kann der Compiler vermutlich auch ignorieren(sonst wäre
__forceinline void f() { f(); }sehr spaßig ;))
aber sagen wir mal in 99% der Fälle hat das ja einen Sinn, wenn der Compiler ein inline ignoriert.
-
rüdiger schrieb:
@net
und __forceinline kann der Compiler vermutlich auch ignorieren(sonst wäre
__forceinline void f() { f(); }sehr spaßig ;))
Compilerfehler.
rüdiger schrieb:
aber sagen wir mal in 99% der Fälle hat das ja einen Sinn, wenn der Compiler ein inline ignoriert.
Ich finde die 99% zwar zu hoch gegriffen, aber es ändert nichts an der Sache, dass ein "echtes" inline, also ein __forceinline, schon manchmal sinnvoll wäre. Mein Compiler kennt leider nichtmal inline und selbst wenn, würde es mir nicht viel bringen wenn ich mich nicht darauf verlassen kann.
-
rüdiger schrieb:
obbba schrieb:
Aber das gleiche kann mir doch auch mit normalen includierten .c oder .cpp Dateien passieren.
Definiert man da auch für jede Datei eine Konstante?.c und .cpp-Dateien inkludiert man nicht!
Heißt das, dass alle Funtionen in eine Datei kommen?
Aber die machen doch gerade den meisten Text aus!
(Allerdings muss man dann nicht so oft andere Dateien öffnen
- aber auch mehr scrollen)Das würde mein Weltbild komplett umwerfen.
Ich hatte doch irgendwo mal gehört, dass man den Code in mehrere Dateien aufspalten sollte sobald er ungefähr die Größe eines DIN-A4-Blattes hat.//edit:
Ich wette man teilt den Code trotzdem auf und setzt ihn dann mit Hilfe von diesen Makefiles wieder zusammen.
Und was soll ich, als verwöhnter Dev-C++ Benutzer, bei dem die Makefiles automatisch erstellt werden, machen?
-
rüdiger schrieb:
aber sagen wir mal in 99% der Fälle hat das ja einen Sinn, wenn der Compiler ein inline ignoriert.
aber sagen wir mal: in 99.2% aller fälle hat es einen sinn, wenn der coder ein 'inline' hinschreibt
TactX schrieb:
Ich finde die 99% zwar zu hoch gegriffen, aber es ändert nichts an der Sache, dass ein "echtes" inline, also ein __forceinline, schon manchmal sinnvoll wäre. Mein Compiler kennt leider nichtmal inline und selbst wenn, würde es mir nicht viel bringen wenn ich mich nicht darauf verlassen kann.
das ist der punkt. ich verwende 'inline' nie, weil's absoluter quatsch ist. wenn ich z.b. gewisse optimierungen einschalte (optimize for speed o.ä.), dann inlined mein compiler sowieso automatisch die funktionen, von denen er meint, inlining würde die ausführung des codes beschleunigen.
wenn ich der meinung bin, schlauer zu sein als mein compiler, dann verwende ich nonstandard-erweiterungen, die inlining erzwingen. soll der code portabel sein, dann müssen eben makros her.
:xmas2:
-
obbba schrieb:
rüdiger schrieb:
obbba schrieb:
Aber das gleiche kann mir doch auch mit normalen includierten .c oder .cpp Dateien passieren.
Definiert man da auch für jede Datei eine Konstante?.c und .cpp-Dateien inkludiert man nicht!
Heißt das, dass alle Funtionen in eine Datei kommen?
Nein, da hast du dich wohl undeutlich ausgedrückt. Ich dachte du meintest mit "inkludieren" -> "Benutzung von #include".
-
Hat jmd viell einen link wo die Modularisierung (bis ins detail also headers schreiben etc) beschrieben wird?
Würd ich mir sehr gern aneignen, in meinen Büchern wirds leider ned beschrieben.
MFG
-
rüdiger schrieb:
Nein, da hast du dich wohl undeutlich ausgedrückt. Ich dachte du meintest mit "inkludieren" -> "Benutzung von #include".
Genau das hatte ich ja gedacht! Also macht man das mit makefiles.
Wenn ich bei der Dev-C++-IDE auf das weiße Blatt oben links und dann auf "neue Datei zum Projekt hinzufügen" klicke, wird die entsprechende Objekt-Datei dann automatisch zum Programm gelinkt?
//Tatsächlich. Es funktioniert... Das ist aber toll...Dass das in Büchern (also in den 2,3 Büchern die ich kenne und in den Internet Tuts) nicht beschrieben wird, stimmt leider.
-
obbba schrieb:
Heißt das, dass alle Funtionen in eine Datei kommen?
Aber die machen doch gerade den meisten Text aus!
(Allerdings muss man dann nicht so oft andere Dateien öffnen
- aber auch mehr scrollen)nein, es ist natürlich möglich alles in einer einzigen Datei zu schreiben, aber wir sind Menschen, keine Compiler, mach das und siehe wie du dein Leben unnötig schwerer machst.
obbba schrieb:
Ich hatte doch irgendwo mal gehört, dass man den Code in mehrere Dateien aufspalten sollte sobald er ungefähr die Größe eines DIN-A4-Blattes hat.
Das kannst du als eine Konvention für deine Projekte benutzen, ist aber allgemein nicht bekannt. Das Aufspalten dient eher dem Programmierer, damit er den Überblick über den Code nicht verliert. Wie gesagt, wir sind keine Compiler, wir müssen den Überblick behalten und damit spaltet man auch den Code auf. Ausserdem macht es Sinn, den Code in "Modulen" aufzuspalten, sprich Code zusammenzufassen (in eine Datei), der zusammen gehört. Das erhört den Überblick, vermeidet man schneller Fehler und ist vor allem beim Debuggen effizienter, weil man die Fehlerquelle besser eingrenzen kann.. Ich habe schon mal Code gesehen, wo einige Dateien kaum 3 KB groß waren und andere (im selben Projekt) größer als 250KB waren.
obbba schrieb:
Ich wette man teilt den Code trotzdem auf und setzt ihn dann mit Hilfe von diesen Makefiles wieder zusammen.
Die Makefile sind dazu da, das Compilieren zu übernehmen (hat nichts dem Zusammensetzen von Dateien oder ähnliches). Niemand sagt, du sollst den Code in Datein aufspalten. Wenn du alles in einer Datei haben willst, dann tue dies, ist aber meiner Meinung nach kontraproduktiv. Dem Compiler ist aber egal, wie groß eine Datei ist.
-
Gut Danke. Schön ausführlich.