Organisation Quelltextdateien: Static functions

[Walter T. (nicolas)]

Guten Morgen,

eigentlich sollte ich diese Frage schon vor lange Zeit geklärt haben, 
aber bislang gab es nach gründlicher Betrachtung nie einen Anlaß, von 
den beiden klassischen *.c und *.h-Dateien abzuweichen.

In einem "großen" C Projekt sind (grob) in den *.c-Dateien Quelltexte, 
die Speicherplatz belegen, in *.h Dateien Quelltexte, die keinen 
belegen.

"static inline"-Funktionen sind in den Headerdateien, weil sie von 
mehreren *.c-Dateien includiert werden (können), und der Speicherplatz 
wird ja auch der aufrufenden Funktion zugeschlagen. So paßt das.

Jetzt habe ich einen Haufen kleiner statischer Funktionen (nicht inline- 
das soll der Compiler/Linker selbst entscheiden), die von genau einer 
Funktion aufgerufen werden. Logisch gehörten sie in die Quelltextdatei 
ebenjener Funktion. Allerdings geht in der schieren Menge dieser 
"Kleinfunktion" die Hauptfunktion unter. Also gehörten sie in eine 
separate Datei. *.c-Datei paßt nicht, weil ich dem Compiler die 
Möglichkeit zum Inlinen nicht nehmen will. *.h-Datei paßt nicht, weil 
sie nur von einer einzigen *.c-Datei includiert werden sollen.

Wie geht ihr bei dieser Klasse von Funktionen vor?

[Where is Waldo?? (Gast)]

Walter T. schrieb:
> Wie geht ihr bei dieser Klasse von Funktionen vor?

a) Als static inline mit in die .c schmeißen und Kommentardichte 
erhöhen.

b) Als static inline in eine ".walter"-Datei schmeißen und diese in der 
.c includieren.

[Rufus Τ. F. (rufus)]

Walter T. schrieb:
> Allerdings geht in der schieren Menge dieser "Kleinfunktion" die
> Hauptfunktion unter. Also gehörten sie in eine separate Datei

Nö, denn das widerspricht dem Konzept von static.

Eine Konvention, damit umzugehen, wäre es, alle nicht-statischen 
Funktionen vor den statischen unterzubringen.

[Walter T. (nicolas)]

Rufus Τ. F. schrieb:
> Eine Konvention, damit umzugehen, wäre es, alle nicht-statischen
> Funktionen vor den statischen unterzubringen.

Das habe ich ja. Dadurch ist immer viel Scrollarbeit zwischen der 
funktionsreichen Hauptfunktion und den Kopfzeilen nötig, weil die vielen 
funktionsarmen Mini-Funktionen dazwischenliegen.

[Yalu X. (yalu) (Moderator)]

Früher habe ich in Fällen wie dem von dir beschriebenen einen Teil der
Quellcodedatei in eine zweite .c-Datei ausgelagert und diese per
#include eingebunden. Dabei war ich mir nie ganz sicher, ob ich der
includierte Datei die Extension .c, .h oder .irgendwasanderes geben
sollte. Schließlich habe ich mich für das .c entschieden, aber auch .h
wäre IMHO in Ordnung.

Heute, im Zeitalter verbesserter Navigationsfunktionen in Editoren und
IDEs mach ich das höchstens noch bei automatisch generierten .c-Dateien.

[A. S. (Gast)]

Walter T. schrieb:
> Das habe ich ja. Dadurch ist immer viel Scrollarbeit zwischen der
> funktionsreichen Hauptfunktion und den Kopfzeilen nötig, weil die vielen
> funktionsarmen Mini-Funktionen dazwischenliegen.

Dann benutzt Du keinen, oder einen unzureichenden Editor.

Seit 20 Jahren (CW als Referenz) bieten alle Windows-Editoren Ansichten, 
in denen z.B. die Funktionen aufgelistet werden. Alternativ kannst Du 
z.B. oben eine Sprungmarke zu den "Hauptfunktionen" einbauen (z.B. 
einfach den Namen hinschreiben und mit einem Click "suchen", auch das 
bieten alle Editoren. Oder Du hast ein Trennungszeichen, dass der Editor 
per default faltet, oder oder oder.

Notepad ist kein Editor.

[Rufus Τ. F. (rufus)]

Walter T. schrieb:
> Das habe ich ja. Dadurch ist immer viel Scrollarbeit zwischen der
> funktionsreichen Hauptfunktion und den Kopfzeilen nötig, weil die vielen
> funktionsarmen Mini-Funktionen dazwischenliegen.

Wenn die Hauptfunktion vor den "funktionsarmen Mini-Funktionen" liegt, 
wie soll dann viel Scrollarbeit nötig sein?

// Header-kommentar

#include-orgie

... lokale prototypen

"Hauptfunktion"

... statische "funktionsarme Minifunktionen"

[Le X. (lex_91)]

Für Module, die aufgrund der Größe/Komplexität aus mehreren .c-Files 
bestehen habe ich oft einen "private-Header".
Da kommt alles an Information rein was in jedem der .c-Files gebraucht 
wird, aber nicht Teil des öffentlichen Interfaces sein soll (z.B. 
interne Datenstrukturen in denen der User nicht rumpfuschen soll).

In so einem Header könntest du sowas theoretisch unterbringen.
Wichtig: diesen Header nicht im public-Header inkludieren.

[PittyJ (Gast)]

Ich nehme C++ für so etwas. Die Hilfsfunktionen sind dann private 
Funktionen.
Die kann man auch in extra Dateien packen. Es steht ja die Klasse davor.

[B. S. (bestucki)]

Walter T. schrieb:
> Wie geht ihr bei dieser Klasse von Funktionen vor?

Funktionen die nur von einer Sourcedatei benötigt werden in die 
entsprechende Sourcedatei, alles andere klassisch mit Source- und 
Headerdateien (die auch privat, also modulintern, sein können). Dabei 
deklariere ich Funktionen, so klein sie auch sein mögen, nie als inline, 
bis ein Profiler mir dessen Notwendigkeit beweist. Ich mag es, wenn 
Deklaration und Definition strikt voneinander getrennt sind, aber das 
ist Geschmacksache.

[1970 wants you back (Gast)]

Es ist 2019, nicht 1970.
Kompilier das mit -lto und das wird auch über Übersetzungseinheiten 
hinweg optimiert.
Nachteilig ist die längere Kompilierzeit.