Hey Leute, İch habe keine Erfahrung mit embedded Programmierung. Nun bin ich in einem großen Projekt mit dabei, wo ich für die Algortihmenentwicklung zuständig bin, ohne wirklich kontakt zur Hardware zu haben, jedoch das Endprodukt eben ein eingebettetes ist.. Ich muss jedoch einige Module/Bibliotheken bei mir einbinden und benutzen, die früher von Kollegen für schwächere Hardware entwickelt wurden. Die Software wurde damals in C entwickelt und meiner Meinung nach haben sie eine schlechte Struktur/Architektur bzgl der Header, denn was sie sehr oft gemacht haben bzw machen ist, folgendes: Es gibt zwei Headerfiles header_a.h und header_b.h und eine Quelldatei code.c. İn header_a werden unter anderem datentypen definiert und typedefs gesetzt. In header_b benutzen sie diese Typen wenn sie Funktionen und weitere Structs deklarieren. Aber sie binden die Headerdatei header_a nicht ein. Die Definition bzw die Implementierung erfolgt in der Quelldatei code.c Hier includieren sie natürlich zuerst header_a und dann header_b, so dass alles kompiliert. Ich finde, dass es ein schlechter Stil ist, aber vielleicht hat es ja einen Grund, wie zb dass man im embedded Bereich das eben so macht da man eben nicht mehrfach inkludieren möchte wegen speicher usw. Wobei das keine Rolle spielen sollte, da ja die ifdefs das abfangen. Wie gesagt, vllt gibt es doch iwelche Gründe. Und die software ist riesig, mehrere zehntausend zeilen code. Deshalb die Frage, ist das einfach schlechter Stil/Gefrickel oder gibt es da Gründe?
Headerfiles schrieb: > In header_b benutzen sie diese Typen wenn sie > Funktionen und weitere Structs deklarieren. Aber sie binden die > Headerdatei header_a nicht ein. Das funktioniert dann halt auch nicht. Oder benutzen sie die die Typen etwa doch nicht, sondern nur ihre Vorwärtsdeklarationen?
1 | struct irgendwas; |
2 | |
3 | void eineFunktion(struct irgendwas *zeiger); |
Das macht man nämlich gerne, um Abhängigkeiten von Headern untereinander aufzulösen. Um einen Zeiger zu vereinbaren, reicht nämlich eine Vorwärtsdeklaration. Auch um (in C++) eine Referenz oder ein Argument zu übergeben beispielsweise. Dazu muss garnicht bekannt sein, wie der Typ selbst aussieht oder wie viel Speicher er belegt (was im Gegensatz dazu bei der Definition sehr wohl bekannt sein muss).
Das halte ich auch für schlechten Stil. Idealerweise sollte meiner Meinung nach die Reihenfolge der eingebundenen Header keinen Einfluss haben und das ist hier nicht so.
Man spart damit die include-guard. Vor 30+ Jahren auch kompilierzeit. Wenn es überall so ist, wäre das allein für mich kein Grund zu refaktorieren.
Achim S. schrieb: > Vor 30+ Jahren auch kompilierzeit. Nö, im C file brauch ich nur einen Header einbinden. :-P Und von ändern hat Keiner was gesagt. Nur sch... Stil.
that 's all schrieb: > Nö, im C file brauch ich nur einen Header einbinden. :-P Deine Ironie in Ehren, aber bevor der UP das noch nicht kennt: Wenn Header mehrfach eingebunden sind, dann mussten sie trotz include-guard jedesmal komplett gelesen werden. Aber das kann es eigentlich auch nicht gewesen sein, denn es geht ja anscheinend nur um (selbst zur damaligen Zeit) Mini-Projekte Headerfiles schrieb: > mehrere zehntausend zeilen code.
Achim S. schrieb: > Wenn Header mehrfach eingebunden sind Das war keine Ironie: - Header A bindet Header B ein - C file bindet nur Headder A ein - Header A, Header B, C file werden nur 1mal gelesen Aber es bleibt ein sch... Stil.
Wenn Du Argumentationshilfe brauchst dann verweise auf: Goddard Space Flight Center, Flight Software Branch: "C coding standards": http://web.archive.org/web/20090411180410/http://software.gsfc.nasa.gov/AssetsApproved/PA2.4.1.2.1.pdf
1 | 2.1 |
2 | |
3 | [...] |
4 | |
5 | (4) The unit header file shall contain #include statements for all other headers required by the unit header. This lets clients use a unit by including a single header file. |
6 | |
7 | (5) The unit body file shall contain an #include statement for the unit header, before all other #include statements. This lets the compiler verify that all required #include statements are in the header file." |
that 's all schrieb: > - Header A bindet Header B ein > - C file bindet nur Headder A ein > - Header A, Header B, C file werden nur 1mal gelesen Ich habe angenommen, dass Header A-Files (die Typdeclarationen) von mehreren anderen Header B-Files includiert werden. Ein H-File, dass nur von einem einzigen anderen H-File includiert wird, und immer mit dem zusammen gebraucht wird, ist natürlich quatsch. (Solange es nicht eine Spezielle aufgabe hat, z.B. der Konfiguration dient und automatisch erzeugt wird oder so)
Achim S. schrieb: > Ein H-File, dass nur von einem einzigen anderen H-File includiert wird, > und immer mit dem zusammen gebraucht wird, ist natürlich quatsch. Nicht unbedingt: Die Betrachtungsebene ist ein Modul. Ein header mit Type-Definition kann in verschiedenen Modulen genutzt werden aber je Modul nur einmal verareitet werden. ;-) [wenn die beiden Module im gleichen Projekt per header eingebunden werden, wirds blöd] Wir reden hier um des Kaisers Bart: - sch... Stil - Mehrfacheinbindung im header verhindern - Reihenfolge der header im Modul sollte keine Rolle spielen Schönes Wochenende!
Bernd K. schrieb: > Wenn Du Argumentationshilfe brauchst dann verweise a-uf: ... > (4) The unit header file shall contain #include statements for all other > headers required by the unit header. This lets clients use a unit by > including a single header file. > > (5) The unit body file shall contain an #include statement for the unit > header, before all other #include statements. This lets the compiler > verify that all required #include statements are in the header file." > [/pre] Das sind die Regeln. Als Argument würde ich mal anführen: zu (4) damit man als Nutzer nicht lange suchen muss, welche header in welcher Reihenfolge einzubinden sind. zu (5) damit zumindest an einer Stelle getestet wird, dass (4) eingehalten wird. Diese best practice haben handfeste Vorteile, die man garnicht so schwammig mit "sauber" beschreiben muss. mfg Torsten
Das VLC Projekt macht das ebenfalls: Viele Header funktionieren nur wenn andere Header vorher geladen werden. Man kann also im Standalone Header nicht wirklich nachvollziehen, was da eigentlich abgeht. Oben wurde bereits genannt, dass dadurch weniger Code durch den Präprozessor muss. Ausserdem könnte man damit in C eine Art Templates implementieren. Nämlich wenn man tatsächlich unterschiedliche Headerkombination nutzt. Dazu gehört auch noch ein bisschen Makro Magie. Die Nachvollziebarkeit geht gegen Null und Debuggen wird quasi unmöglich gemacht.
Mir wollte mal ein (Ex-)Kollege weismachen daß include guards nur von Leuten benutzt werden die nicht imstande (oder zu faul) seien die Reihenfolge der includes ordentlich zu organisieren, Er halte davon gar nichts, er brauche keine Include Guards. Auf die Gegenfrage was er denn dann machen würde wenn zwei Header den selben Header einbinden müssen hat er mich erst 10 Sekunden angeschaut als hätte ich gefragt aus welcher Käsesorte der Mond hergestellt ist (diesen Blick hatte er wirklich gut drauf), danach hat er mir dann kurz und knapp erklärt daß seine Header grundsätzlich gar nichts includen würden. Mindestens zweimal am Tag hab ich ihn fluchen hören weil ihm mal wieder irgendwo an anderer Stelle ein #include verrutscht ist. Und das trotz (bzw. nachträglich sag ich mal zum Glück) eher mäßiger Komplexität des betreffenden Projekts.
Bernd K. schrieb: > Mir wollte mal ein (Ex-)Kollege weismachen daß include guards nur von > Leuten benutzt werden die nicht imstande (oder zu faul) seien die > Reihenfolge der includes ordentlich zu organisieren, Er halte davon gar > nichts, er brauche keine Include Guards. Praktikant?
Bernd K. schrieb: > Mir wollte mal ein (Ex-)Kollege weismachen daß include guards nur von > Leuten benutzt werden die nicht imstande (oder zu faul) seien die > Reihenfolge der includes ordentlich zu organisieren, Selten so gelacht. Natürlich müssen Includes so gebaut sein, daß sie völlig unabhängig von der Reihenfolge laufen. Sie können daher nicht darauf vertrauen, daß im C-File eine Reihenfolge eingehalten wird. Damit macht man sich das Leben nur unnötig selber schwer, d.h. man verzettelt sich leicht. Ich sortiere sie alphabetisch, damit ich Doppelungen leicht sehe.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.