mikrocontroller.net

Forum: PC-Programmierung Organisation Quelltextdateien: Static functions


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Walter T. (nicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

: Verschoben durch Moderator
Autor: Where is Waldo?? (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Walter T. (nicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: Le X. (lex_91)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: PittyJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: B. S. (bestucki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 1970 wants you back (Gast)
Datum:

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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.