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?
Gast
#5923280
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.
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.
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.
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.
Gast
#5923474
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.
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?
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
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.
Gast
#5924199
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.
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.
Gast
#5925001
Es ist 2019, nicht 1970. Kompilier das mit -lto und das wird auch über Übersetzungseinheiten hinweg optimiert. Nachteilig ist die längere Kompilierzeit.